Yes, in practice this increases price transparency. Imagine everything could be monetized. They could charge for access to the bathroom, or water. What is the minimum expectation of what is included in the price of a ticket?
I'm against charging for bathrooms, water, or other such basic human needs while you are in the custody of the airline for the duration of travel. There should be a basic standard of human care that includes those things. Food should also be included for flights over 5-ish hours.
Carry-on fees are a whole another level of shittiness though. I, the customer, am the one carrying the bag, there should be no reason to charge for it.
It's like charging extra for wearing a red shirt or charging extra for wearing a hat.
> I, the customer, am the one carrying the bag, there should be no reason to charge for it.
It's on the plane, so it takes up some of the limited storage space, and increases the weight of the plane, which means more fuel burned.
Saying you carry the bag so there's no reason to charge for it is like saying you carry yourself onto the plane, so there's no reason to charge you for the flight ticket.
So either they build the average per-passenger cost into the price of every ticket, or they charge a fee only for people who want to take on the extra bag.
In practice, flights.google.com doesn't know the price of a luggage. So you might think a Easyjet/Ryanair ticket is cheaper, but I have had situations where actually after adding the luggage for every passenger the normal airline is €30 cheaper in total. And you get a free drink plus snack.
Honestly, it would be much better for transparency reasons if budget airlines offer a discount for no luggage instead of an extra fee.
I have incontinence, so I either wear diapers (still going to pee and defecate regardless), or I have access to the bathroom in time. If I wear diapers, there is going to be odor contamination in the area. It is bad for others, and for me, and their business too, I assume. Depends on the length of the trip; I try to limit fluid intake to zero before I go outside.
At peak season every year, O’Leary says something crazy like they are going to charge for the bathroom, or charge fat people extra, or get rid of arm rests, or have standing room only. The tabloids run the story, and always mention how cheap the flights are, including whatever the cheapest deal at the moment is.
It’s very, very obvious advertising. The tabloids go along with it because it makes people angry, which drives traffic.
Up until 1978 there was a lot more than this in the US. This is where we see photos of carts that brought prime rib to passengers and people in suits toasting with champaign glasses and there was so much space in the aisle that you could pass by service carts. It was like that because airlines were extremely regulated and not allowed to compete on price. So they competed on what was included. The result was photos of "a more civilized time" but also that almost nobody could afford to fly.
This design is unstable and expensive to produce with a complicated in wheel transmission. It is novel, but almost certainly more expensive and less reliable than existing designs.
In wheel gears have been in use for over a century very successfully. I had a Raleigh bicycle with Sturmey Archer gears as a child. It never gave me any trouble, unlike the derailleur gears I had on later bicycles.
> In wheel gears have been in use for over a century very successfully.
They've been barely viable the whole time. Sturmey Archer are the last maker in business; they went bankrupt a couple of decades back and for some years there was serious concern that manufacturing would never resume.
...what? There's a whole bunch of manufacturers, so many that there's an entire Wikipedia page disccusinge them at https://en.wikipedia.org/wiki/Comparison_of_hub_gears. There's at least 8 different manufacturers on there, some with many different models. Some were introduced as recently as 2023, so it's hardly some abandoned legacy technology.
It's true that internally geared bikes are common, especially in Europe. But internal gear hubs that are coaxial with pedals are almost unheard of. The only production one ever is the Schlumpf Unicycle hub, which costs $1500 and only a few hundred have ever been made. It also has only 2 gears. It's certainly possible to do, but I have doubts about a company opting for that incredibly expensive option of creating a new hub instead of reusing standard bike parts.
You've not come across hub gears on bikes before, have you? They were pretty much the standard before derailleur gears became popular, and modern ones can have up to 7 speeds.
I’ve ended up with some electronic road SRAM which is seriously quick in comparison (except for the slow rider), but do miss the smooth internal hub and the stationary gear changes.
Oh, nice, the state of the art has advanced since I last read about hub gears, which was ... oh dear, about twenty years ago? No wonder things have improved :)
Fennel has actually convinced me that Lua and lisp have more in common than one might think. I don't know what the above comment was referencing, but I've always found beauty in lisp languages for having a primary datastructure that all others can be abstracted to. Lisp, classically, has list, clojure has sequences, and Lua/fennel has tables.
Fennel is phenomenal, and is the reason I switched from chicken scheme to clojure/babashka despite hating the JVM. Neovim config, Wezterm Config, and various scripts to do things are all now written in fennel. I've also used it for game dev using Love2D.
It's a great great language, and fixes a LOT of the issues I have with Lua.
> Javascript is Lisp in C's clothes? On what basis?
On a lot of bases. Javascript has real lambdas, a sort of homoiconicity of code and data (hence JSON as a data format), also has the same dynamic take as lisps on "types belong to data". Rather than variables types belong to values. Brendan Eich's original idea was literally to "put scheme in the browser" and you can in fact pretty easily convert the Little Schemer to JS.
Saying two languages don't have much in common because they don't have the same syntax is a bit like saying we don't have much in common because we don't have the same hair color.
> a sort of homoiconicity of code and data (hence JSON as a data format)
I get that "sort of" was an attempt to hedge, but really, this isn't even close. Homoiconicity here would be if all javascript source files were valid JSON documents. A weaker version would be if it were common to use JSON to represent an arbitrary javascript program, but I've never heard of that, either. (For a good explanation of this weaker sense of homoiconicity, this stackoverflow page [1] is pretty good.)
To use Clojure as an example of a language that is homoiconic, you can take any Clojure source file, send it to an EDN parser (EDN being Clojure's equivalent of JSON), and not only will parsing succeed, but the result will be a complete representation of the program (you could execute it if you wanted to). In contrast, if you try to send JS to a JSON parser, you'll get an error as soon as it hits a function definition, or a for loop, or an operator, or whatever.
But MacCarthy's original LISP 1 and LISP 1.5 do not have real lambdas. The lambda feature parametrizes a piece of code as a function literal, but doesn't capture anything.
What they have is code parsed to a data structure, which is then susceptible to manipulation by the program before being executed. JS has some dumb textual eval, like the Bourne shell.
Javascript hotloading development setups are about the closest you can get to the REPL development loop outside of lisp. I'd imagine lua is similar if the embedding is set up for it.
Revise.jl in Julia (https://docs.julialang.org/en/v1/manual/workflow-tips/#Revis...) also gives a really neat REPL development experience. It allows tracking changes to any source code file, module, even standard libraries or the Julia compiler itself!
I hate to be that guy but a ton of languages have REPLs. The whole collection of smalltalks out there are basically an interactive environment. All of them forth languages do it too. Factor, Racket, LiveCode, there are so many. And for most of them, watching files and hotreloading is not how they do it.
To whoever down-voted me, please do explain how HMRs are comparable to Erlang's true hot code swapping or even Lisp's live redefinition.
HMR is limited to modules (almost or always UI components), and there is no native VM support (module boundaries, side effects, and global state complicates it further) for it, and there is no multi-version coexistence either, and it is absolutely not suitable for production.
To call "hot module replacement" hot loading is very generous, and quite an overstatement.
It is only very superficially similar to hot code swapping. It is a developer tool, not a foundation for live, fault-tolerant systems.
It is absurd to call hot module replacement (HMR) "hot reloading". It might sound fancier, but it is nowhere close to true hot code swapping.
Peak redefinition of terminology. Call it what it is: hot module replacement, at best.
Hot module reloading is common in JS land and does things like trying to preserve running state as opposed to just watching a dir and restarting everything.
Lisp killer features were GC, good data representation, first class functions. Lua has all that and more. But its being a "thin" library over the C runtime shows through the clothes.
Also, I do want to point out that despite very recognizable syntax, that's not the only thing that makes lisp lisp. Primary example of lisp-y syntax on a non-lisp would be Janet [0]
I would argue yes. There's a lot of things that I expect to work in a lisp/scheme that just don't work in Janet. Many of those things being related to cons/car/cdr stuff. That said, it's still a fantastic language.
I have an intuition that the comment you're responding to has a lot of truth to it, but I am going to have to educate myself to give you an answer.
One thing I do know is that JS and Lisp both treat functions as first-class citizens, allow some degree of meta-programming, and rely heavily on hierarchical (e.g., nested objects in JavaScript vs. s-expressions in Lisp).
Passing functions by reference enables both LISP and JS to compose higher-order functions and, as suggested in another commented, both Lisp and JavaScript's "dynamic stack frames" somehow live updates to running code without requiring a complete restart of the application. The only clear example of this I can find, however, is Bun's --hot mode, which performs a "soft reload," updating its internal module cache and re-evaluates the changed code while preserving global state.
I have some vague notion that this is a favorite feature of Lisp, but it's not clear to me that it's unique to these language families.
---
Edit: Lexical scoping, closures, some tail-call optimization...
---
Edit 2:
> Programming language “paradigms” are a moribund and tedious legacy of a bygone age.
(Dave Herman)[0]
---
Edit 3:
> The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures."
> Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.
> On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.
Interesting way to apply concepts from the terminal to the GUI. Looking at this from my naieve perspective, it seems that all of this is doing is emulating the accessibility of the terminal. You have an easier way to run programs with per-determined args- something you could easily do with shell scripts.
What a very novel UI! I like it a lot! It makes a lot of sense for people to cascade files left to right, especially when people have more widescreen monitors.
Some of the noise is also there in German, cf https://de.wikipedia.org/wiki/Bergfried (the English page has the same name, but does not mention Burgfried). Just an example, could be very well unrelated.
reply