ecl and gcl compile to C. That's fine, but not necessary to merely use C libraries; for that you need a C foreign function interface (FFI), which most surviving CL compilers offer. C++ is more of a challenge, hence the Clasp project.
I feel like Clasp has huge game development potential but has gravitated towards science just because that's where it came from. Like surely one could use it to get good godot bindings for example, but I haven't seen stuff like that around.
jank is also garbage collected, since Clojure practically demands it. Currently using Boehm, a conservative GC, but we'll need to switch to something more competitive when that becomes a priority. I have my eyes on MMTK + Immix.
Well, I don't think there was any consensus. Atari played on this with the "ST" (for sixteen/thirty-two) product label. From the software side it was 32bit. The flat, huge (at that time) address space made things so much easier (compared to the awful segmentation of the Intel CPUs then). That the ALU was just 16bits meant that some operations took longer than one would have liked, but was otherwise of no concern. No "far pointers" or any such crutches.
That's how I see it. As a developer, you still used 32-bit math operations in assembly and the CPU executed them as a series of 16-bit ops. The details are abstracted away. IMO, that made it 32 bits.
By analogy, SATA is a serial protocol, but you wouldn't ordinarily refer to it as a 1-bit bus.
"Meanwhile, the Concorde continued its effortless cruise toward New York’s JFK Airport."
i.e. it used only 4,800 US gallons per hour of fuel (a 747 burns around 3600 gallons/h). Not what I would label "effortless", but not nearly as bad as I expected.
Interesting, but I wonder whether that's not due to some misunderstanding. In Germany the employer pays half the social security and health care costs, which is not considered part of gross, because, well, it's not the gross income of the employee, but part of the cost of the job to the employer (and of little concern to the employee).
Ultimately that's just an accounting trick that makes it appear like the government takes less than it actually does.
What we really care about is how much the government takes from us ("total cost to employer" - "net payment to employee") and what it provides in return.
In some sense, it doesn't matter at all if the tax is paid on the employer or employee side.
But in reality, it matters a lot when the tax burden is raised or lowered. Either the employer or the employee will be paying more or less. It's not the same at all. And the people making the decisions know this difference, for sure.
But the amount taken from the employee is "total gross salary for employee" - "net payment to employee". Any additional expense borne by the employer due to additional tax is taken from the employer. (Same goes for other overheads such as insurance, cost of equipment, cost of working space.) The distinction is relevant because the employer has other things it could spend the money on, such as giving it all to the shareholders. Or buying more equipment. Or just storing it in the bank for a rainy day. Or maybe even employing more people at the existing salary levels. It's always felt to me that it's counting this particular bit of tax as the employee's money that is the trick.
But, I won't deny that our hypothetical employer could also give people a pay rise. And maybe this would translate into higher salaries generally over time. Not impossible! It's all the same pool of money!
But in this scenario, the amount of money doesn't change. It's just a matter of defining what percentage of the total salary cost of employee is attributed to the employer vs employee.
For example in Estonia, if you hired somebody for 1000 EUR gross salary (the number that you'd put in a job listing), the employee would receive 896 EUR on their bank account and the state would receive 442 EUR as taxes from the company. This means the cost of this employee's salary is 1338 EUR (1000 EUR gross * 33% social and 0.8% unemployment tax) to the company. This is not optional, the company can't decide to pay less or use the money for other purposes. This would show up as 1000 EUR in statistics for average salaries or comparisons like this.
You could shift this tax burden between employer / employee arbitrarily and say for example that starting next month, social tax will be counted as part of gross. However the employee would still receive 896 EUR to their bank account and the state would still get 442 EUR as taxes and the company would still pay a total of 1338 EUR, but the average gross salary just went up by a third, while nothing actually changed.
> But, I won't deny that our hypothetical employer could also give people a pay rise
It is money allocating for having that employee in the company - it could all go to the employee as far as the company is concerned. It is worth considering how much of that total money the company is spending goes as taxes, and not just the bit that counts against income tax scaling.
Right, and why not? The situation would be exactly the same in terms of how much money goes to employee and how much to tax.
But these arguments are always made with the implication that things should change, because otherwise what's the point? And in this situation, suppose things did change, and the tax rates were reduced: now the employee would get the same amount (they weren't paying any tax!) and the employer would get more (they were paying all of it!). And if this applies when the employer pays all of the tax, when it's perhaps obvious this part of the tax burden wasn't the employee's money, it applies when it pays part of it.
(Of course, reading the thread again, this depends on what the definition of "we" is...!)
> We identified discrepancies in Medley’s Common Lisp implementation by testing against the examples in Practical Common Lisp by Peter Seibel.
Huh? While PCL is a great introduction text with practical examples, I doubt its suitability as ANSI CL standard compliance benchmark; it surely wasn't meant as such. Why not use Paul Dietz's ANSI test suite?
The tests against Seibel's book were meant as a quick way of assessing the major differences with ANSI. But books like this are also a way of exercising the part of the language that is used in practice. We do mean to follow up with more in depth investigations, such as running a test suite like Dietz's.
reply