tailrecursion

Exactly, if you're a business in a political climate of any kind you have to keep up appearances regardless of your private beliefs.

Somehow I don't think Eich and supporters of Prop 8 would characterize it that way. You believe that Eich is evil but it is possible that he is on the correct side of the issue and you are on the incorrect side. In any case he was participating in politics just like everybody does and should. He was fired for disagreeing.

The bicyclist was fired because she worked for a government contractor that felt it necessary to do its own kind of virtue signalling, to ward off the potential for lost business.

Forth IS different in one way, from most other languages. The syntax doesn't mark which parameters are being passed to which functions. In C for example you have parentheses and commas that provide that information to the reader. The marking of parameters-to-functions helps most readers read a program and determine its meaning.

In some cases it doesn't matter which parameters are going to which functions, and the reader can get a sense or enough of a sense, from the choices of names the programmer made. You can get by without knowing.

But in many cases it is vital to know which parameters are being passed to which subroutine, in order to understand an algorithm. For most people, having to puzzle and re-puzzle this out while the program is being studied is too much extra work or extra ambiguity, or, they just don't buy having to put up with it, given the ready alternatives.

Those specific markings -- parentheses around function calls -- makes a big difference in readability overall.

To clarify a little Chuck's projects were not rewrites in the usual sense, but they can still be read that way, as derefr suggests. His famous BASIC compiler for example was an implementation of BASIC, something that's been done a thousand times before but Chuck's was not a rewrite of any particular program.

Much of Chuck's code reduction comes from simply not implementing parts of the problem that most people would not think of eliminating. Other parts he will eliminate that most people would think inconceivable to eliminate.

Other "secrets" of Chuck's ways are that he uses the CLI as a front end, or, spends a great deal of time working on an algorithm and finds a simpler way that is good enough in the application he's working on today. So instead of spending time optimizing for speed or modularity he's willing to specialize his subroutines per application to optimize for concision or simplicity. Somewhat like Woz's optimization to save chips.

I bet most people who investigate Chuck's methods will feel disappointed that the methods don't seem as clever as the end product. What I think most people can take away from Chuck is skepticism about the utility of most programming technologies, which do automate tedium but tend to substitute their own architecture and complexity, for a net loss.

When I see a statement such as, Income in men declined 10-19% over several decades, I think:

OK. Why? Is the ratio of young/old different from before? Were those living on social security included in those stats? What does that have to do with wages? Is it because men are choosing different jobs? Is it because they are working fewer hours? Is it because they are choosing to earn less, because cable TV and internet connection are enough? Is it because cars cost less? Is it because, generally over the population, men are choosing activities other than work? Is it because feminists have changed women who have changed men into deciding not to marry women, generally over the population, which reduces the drive or opportunity to pursue larger incomes? Is the pay hidden somehow, more now than before, going to medical costs instead of salary?

The conclusions in the news article depend heavily on definitions for "middle class" and "workers" and seem to assume that wealth equals money and that income equals wages.

You may be on to something, and you're right there is Robusta available that is supposed to be good.

Another difference is that American crafty houses are roasting lighter than in Italy. For whatever reason, Americans are following a different craft and not optimizing their espresso recipes nearly as well as the Italians and not using the same goals and procedures as they do.

And frankly I'm convinced some of the roasters simply don't know what they're doing. They've been told that roasting light is good, and they don't realize that light roasting with espresso brewing is risky. Especially with bean types that are known to be acidic.

There are three possible reasons for the quizzical look you get.

1) They misunderstood you to mean that you have no money and that you will run aground any minute. Whereas in reality you're fine for now.

2) What you got was a "first reaction" from someone caught up in money worshipping. People sometimes act contrary to their personal beliefs for the purposes of conversation.

3) You're making a horrible miscalculation and you're fated to be punished by unseen forces.

The author argues that a random access to memory is not O(1) but instead O(root N) because of distance.

The easy reactive response is that with respect to algorithm design the size of RAM, N, is a constant.

On the other hand for very high scaling factors, as input size rises the size of RAM must also rise. In this way N can be thought of as a variable and that seems to be what the author is thinking. Different algorithms will behave differently as they are scaled to infinity and beyond.

I think the author's argument is interesting but maybe it's better to make new models for time complexity analysis. I think Bob Harper's students have done good work on this.

In addition to distance there is also the cost of selection, namely the muxes and decoders, which would multiply the cost of access by log N.

If people want to use snazzy services but don't want to pay, and then outlaw collecting private information, presumably the owner of the snazzy service will find some more complicated or secret way to monetize its users?

In my opinion this is the most important insight into Smalltalk: that Smalltalk is renaming indirect function calls as "messages". If Smalltalk message passing were asynchronous, and if Smalltalk objects were processes, then Smalltalk would be closer to the vision that Kay conveys.

I believe it was Jonathan Rees who emphasized the relationship between Smalltalk's messages and generic functions.

Real objects are processes.

Alan Kay has had many opportunities to specify precisely what he means by objects and messages, and based on reading his more recent (or less old) VRI papers, Kay draws inspiration for objects from biology, where swarms of molecules pattern match against the partially constructed molecule and build it up step by step. I've seen him give an example in only one paper.

Needless to say this is not how Smalltalk works.

There are some comments here about the difficulty competing with Chinese knockoffs, but there are many small companies making high quality 3D printers, and they have good reputations: Ultimaker. Printrbot. E3D BigBox. Makergear. There are probably many others too that have been around for years but I'm not really plugged in.

Thomas Sanladerer on youtube is a good source of information, and reprap.org, if you're shopping.

By the way Mr Horn is head of VW Group of America, a subsidiary which besides operating a factory in the U.S. is more or less a distributor of cars for VW and related brands in the U.S. As other people have said Horn doesn't know what's going on at VW AG.

Also, judging from an earlier article it appears it's common to refer to various higher-ups on the product teams as Engineers even though they are quite old and were clearly acting in a managerial or even executive capacity. When Horn says "software engineer" he's making a leap and it's the wrong leap.

Horn is making these statements after being pressed by members of Congress, he's not volunteering these misleading statements.

There's a crucial decision the Toyota engineers made, as described by the article, which was that if the stuck accelerator was not preventing the driver from using the brake and slowing the vehicle, then the stuck accelerator is acceptable (we're talking about a small number of reports) and no fix should be made.

It's not easy to understand why they would make that decision. I imagine a stuck pedal is likely to cause confusion in a driver. It would take some time before a driver will process what is happening, and realize that the accel pedal is indeed stuck. It seems like surely it would cause accidents.

Furthermore, it's not a tough problem to design a pedal that moves back and forth in high humidity or high temperatures that a car interior is going to see. And it's not expensive.

But we're seeing this fault in isolation. The engineers are likely thinking, "Suppose we fix this problem. That's fixed, and it cost $2 per car. Now, what are the 1000 other items that could fail and cause a similar moment of confusion, of the kind that might contribute, or seem to contribute to an accident? What will it cost to fix all of them, because fixing just one doesn't solve the problem."

Intel's compute stick strikes me as a vehicle for "Windows 8.1 with Bing", which also appears in cheap laptops. There are already many powerful followons to the Raspberry Pi, with 1-2 GB RAM and up to four ARM cores for $40-$100. Microsoft must have jogged Intel and said, Do something!

For example an automobile can be thought of as an emitter of pollution, if your problem concerns pollution, or, it can be thought of as a particle, if your problem concerns traffic congestion.

The auto "fits" into each of these different problem domains.

If we redefine the word "OOP:object" to mean process-with-mailbox, and redefine the word "OOP:message" to mean asynchronous message passing, then objects and messages make sense and are useful.

Those are not Smalltalk's definitions -- even though I think you're right on about Alan Kay's original inspiration -- and confusion can arise if we redefine terms.

Sam, Chuck designed the Novix but the Harris RTX 2000, which is very similar, was designed by others.

These are 16-bit chips (the Novix addressed 128 KB) that use dedicated stack memories, that's 3 ports to memory total. The RTX puts the stacks on chip.

The nice thing about these CPUs is they can do stack, alu, and return in parallel, interrupts are cheap, timings are predictable, and programming model is nice if you like Forth. One disadvantage of the design is that clock rate is limited. RAM fetch and instruction processing have to fit between pulses meaning RAM has to be approx twice as fast as clock.

I imagine that making user functions would require leaving the one-symbol-one-function spelling system that J programmers are accustomed to, and that spelling system is part of the appeal. Also, if the idiomatic form with primitives is shorter than the name, it's tough to consider the name an improvement. :)

Thanks for your response.

After reading a lot of K code I had the same experience, where word-based programs now read like someone from the Slow Talkers of America.

Learning APL, I was skeptical of its symbolry. But, by avoiding (verbal) mnemonics the symbol becomes its own thing, it has very specific meaning that is unique to APL. I can see the value in manipulating those very precisely understood symbols once a person knows the language cold.

J however remains above my pay grade.

I've been struggling to learn J for a few weeks, and there are several things that make it difficult.

1) Lack of spaces in the majority of code make it difficult to lex let alone parse, meaning I can't tell what the operators are. When people use spaces it makes a difference.

2) Every operator has at least two meanings. Some have three meanings. That's more than 100 operators to memorize and 50 share the same spelling as the other 50.

3) The parsing rules as described strike me as extraordinarily complicated.

The ideas in APL are worth learning. For example striping objects and using grade up to make a concordance or annotate any other data structure. Another example is having the primitives auto-sort collections when searching to get nlogn complexity. Almost any language can use these ideas. If Python is one step up from Standard ML because of dicts and out-of-the-box primitives, then APL is one step up from Python.

If anyone who knows APL well is around, can I ask some simple questions?

1) Do user functions and if statements vectorize? Meaning, if I write a recursive function to implement Euclid's GCD and then pass it two arrays, will it give an array of pairwise GCDs?

gcd(a,b) = if b=0 then a else gcd(b,a mod b)

where = and mod are both vectorized APL primitives.

2) Why do I see so few user functions being used? I would expect application code to consist mostly of specific functions but instead I see line after line of unbroken primitive operators.

(EDIT: fixed formatting.)

Yes. Turbos make sense but if Volvo is betting on them they are only joining VW, BMW, and Subaru.

Your remark about the i3 is due to its range? Otherwise it is a good car. Tesla's products are very attractive partly because of Tesla's commitment to supercharger networks (which are no cost to use) and other recharging infrastructure. BMW's story seems weak by comparison but their EVs are good so far.

I'm thinking of a system with valueset inference where valuesets are not necessarily disjoint. So the system may infer that a return value is the disjunction {INTEGER | REAL}.

In order to get precision in checking, a lot of computation needs to be done so the compiler relaxes the precision when facing large disjunctions (networks) of constraints.

Dynamic checks are inserted as necessary but a system that relaxes when things get hairy can't guarantee that it will find all errors at compile time.

The idea is similar to Soft Typing of Cartwright and others, but they were thinking of an interactive system, some kind of programmer's aid. If I recall they ran into problems giving reasonable error messages.

I want to question the importance of soundness in type systems. Suppose you could catch 99% of type-based errors instead of 100%, and in addition, use a compiler switch to see all the case statements where a class of a type is missing. The intended benefit of this system is that it accepts all correct programs. Correct meaning, the program runs and returns the correct answer.

Would such a language be viable? Or is it absolutely necessary to catch all possible type errors. In the past, tools like lint have been considered useful, although lint is not at all the kind of type system that I envision, namely a system that is in practice catching all the errors that ML catches -- it just doesn't (and cannot) guarantee it catches them.

The restrictive nature of static type systems today is legendary, but I wonder sometimes whether people realize how restrictive they are. If you can't make your idea work with functors or typeclasses, chances are good there's no way to get it to compile and you have to write functions in longhand.

Kazinator's comment struck me as a lucid definition. APIs and ADTs let the thing's behavior define the thing, and subtyping and substitutability emerge from thinking about generic operators defined on more than one kind of datum.

My bet is even Smalltalk programmers don't think of eggs as knowing how to scramble themselves; but eggs do have an API, a behavior, that makes them distinct from other kinds of objects and at the same time shares characteristics with other objects, such as weight and dimensions.

I can assemble a list of eggs, elephants, and cars, and write "take the sum of the weights of all the objects". Although these objects are of different kind, they share a common characteristic that would be exploited naturally by any language user. Exploiting multiple "views of a thing" is a feature of English ("natural language") and to my mind is a feature of any successful "generic programming" computer language.

Processes communicating by asynchronous message passing is a better simulation of the familiar world; but that vision is not realized by Smalltalk, wherein messages are passed synchronously. What we want from language is the ability to write powerful sentences and have them mean something to the machine -- as long as the computer and human agree on the meaning. The better part of this power comes from a sophisticated treatment of type and generic operators.

As rants go this one is good because it identifies some language features and misfeatures that are important, such as type system complexity. But Will Yager's recent article was much better: partly because it was not a rant, and partly because it succinctly covered all the bases.

We've reached a point in time where there is a wider consensus regarding the importance of stateless programming, option types, code re-use, and the productive people are not complaining anymore and instead are doing something about it. There are many new or recent PL projects ongoing, where people are designing new languages.

In the mean time, for those people who roll their eyes at missing GUIs or support for email addresses -- it seems to me they've identified an opportunity.

There is a rich set of choices out there and the hard thing (for people who aren't designing their own language) is shopping. Those people who can make effective decisions and exercise good judgement are going to have an advantage, whereas other people who expect others to deliver popular platforms into their hands for free, will remain below average.

I think if you're going to make a strong criticism of a complete design and implementation that includes decisions that were almost certainly made deliberately, then you owe an explanation or some kind of argument.

My position is that it's the language's job to allow expression of ideas and not its job to police or disallow bad sentences. I think such a thing [EDIT: disallowing bad sentences] is impossible and leads to COBOL-like languages. (Compilers can have options for coding standards, like "house rules" but I don't think it's the language's role.)

In the 60s, operating systems were designed in a world where the person running the program was the same as the person who wrote the program. Today many of the security or privacy schemes start by making a distinction between the programmer and the user.

Besides sharing or "abstracting" the pieces of hardware that the app wants to control -- as VMWare or a hypervisor might do -- the operating system has one additional important role, which is to function as an agent for the user.

The apps, written by various persons, are running on a computer that belongs to the user. The operating system keeps control of the computer -- the user's computer -- in the user's hands, and keeps it from being "taken over" by the apps.

This role or function of the operating system can certainly be subsumed by a programming language / environment like Smalltalk or Java, but the idea of an operating system has a purpose that directly reflects the different interests, goals, or priorities of distinct entities interacting inside the machine.

Usually the master control program is seen as being against the users, but I'm casting it as a good guy. I think that the promise of the operating system is that it can be a good guy (for the user), even if real examples tend to fail at that job.

My understanding is there are a number of things that have to be right. In addition to rigidity and precision of the machine itself (bushing quality, rod runout), the speed, layer height, temperature, and filament regularity are all important to quality. There are other software settings that impact quality as well. Bed leveling in a machine that doesn't have software auto-level is another big one.

If you know the stepper motor specs you can calculate the resolution. Most motors are 1.8 degrees per step and most controllers use 16 micro steps. If the GT2 pulley is 10 mm diameter, that gives 0.01 mm per micro-step.

If the machine is not rigid and precise then you won't get full capability but 0.01 mm is very good and may be more than needed given the capabilities of the plastic, and the layering process.

I recently read up quite a bit on FDM robots, and in my opinion it would be a shame to pass up the opportunity to build a robot yourself, and even design one yourself. The cartesian machines are more or less variations on a theme, and most use the same set of standard parts: nema 17 motors, acme screw shaft, linear rods, linear bearings, 608 bearings, and GT2 pulleys and belts.

Check out Misumi's catalog, and you can always roll the dice on shady-Chinese-company knock-offs (Robotdigg). Look up aluminum t extrusions for framing, or use sheet or square tube. Or buy a frame from tens of vendors who sell kits and parts for the Prusa Mendel. I don't like the swing-set Prusa, and I don't like threaded rods. But there's also the fine Makergear M2 for inspiration.

Electronics and software are also commoditized.

Good kits if you don't want to design your own:

Printrbot Simple Metal Rigidbot (I don't know if they are using the best parts) many other quality kits

Interesting robots:

Reprap Wally, designed by Dennis Brown & Nick Seward.

3d printers are one area where it is the Wild West, you can go as deep as you want in one week, and learn almost everything except software details. All the hardware is nearly standardized, and right out there to look at and study.