This is why there is growing anti-AI sentiment. It is always extractive. You can never just enjoy a poem, you need to use it. You need to extract its value for shareholders. Get a life.
Creatives have always found inspiration from what they consume (AI has nothing to do with it). My partner writes, and eventually gets to the point where she has to take a break from plotting and writing and watch tv shows or read books. When she says she needs to refill her well, I know she's about to want to watch tv shows again for a little bit.
I design games. I can't even count the number of times something someone said, or a game I've played or watched a review of, has sparked an idea for new game, especially a board game (which most of the time doesn't work out once it gets in front of players, but that's okay). It's probably been over a hundred times by now.
People love highlighting quotes from poems and stories that they find inspirational for their own lives somehow. You want to know how I know? Kindle used to tell me, with saying how many other people highlighted a specific passage (it might still do that, but I mostly listen to audiobooks right now, so of course I won't see them). Also social media is flooded with people sharing quotes from various books or poems or sayings from people.
That's all this is.
But because it's said by someone who works with A.I. and thus is thinking about the quote with that frame of reference, you had to twist it into some anti-A.I. sentiment, implying that he's doing something perverted or not normal by daring to find inspiration in a quote.
Bukowski was a fan on new technology even towards the end of his life:
> “Yes, you have a strange project: electronic books. It might be the future as more and more people find that the computer is such a magic thing: time-saver, charmer, energizer.”
No one can say what he would have thought of AI for sure but I think he would have appreciated ability to reduce drudgery on this thoughts on factotum[1] work.
1. Why yes, that is a cheesy reference to his book of the same name. ;)
> On Christmas Day, 1990, Charles Bukowski received a Macintosh IIsi computer and a laser printer from his wife, Linda. The computer utilized the 6.0.7 operating system and was installed with the MacWrite II word processing program. By January 18 of the next year, the computer was up and running and so, after a brief period of fumbling and stumbling, was Bukowski. His output of poems doubled in 1991.
This cracked me up. I only used ~~one~~ two of his poems and enjoyed most of the others. Betting on the Muse was $2.09 on Amazon, which is a good ROI, I think.
Bukowski worked as a mailman. I had that job too. It was an awesome job. I got through like 9 hours of audiobooks a day.
Only issue was nobody sends mail anymore -- the elderly, Christmas and spam -- so when there was no mail, you'd work an hour and then you'd only get paid one hour. So most people were students, or their spouse did the heavy lifting.
Other than the pay, it was a great job though. I worked in snowstorms (and regular storms!) and in >37C (~100F) -- I got a big sombrero which looked a bit silly but did the job.
Then I'd go home and work on genetic algorithms. And then when the pay arrived at the end of the month -- 800 Euros (909 American), I had to wonder if I wasn't doing it backwards -- I should be getting paid to work on genetic algorithms all day, and then at the end of the day I should run up and down staircases for several hours for free.
The terrible thing is that everything is moving to apps so that the developers can get more access to the user's fingerprint and get more data. Get access to photos, location ect. All webpages that suddenly have an app, which in my experience ends up having less functionality than the website, are quite simply there to get data, and be able to push notifications. They are parasitic. I miss the days when an app was the better offering but it isn't anymore.
What a great tool and community they have built. I find my flipper0 is like a computer Swiss Army knife. It’s so fun to carry around a tool of my own trade.
Sdks/libs, especially open source sdks, were never about gated knowledge. They were about the providing company making it as easy as possible for you to integrate. You would not need to know the idiosyncrasies behind api retries, paging, rate limits, auth flow, and on and on. The third party developers needed a resource, they call a method and get it. Open source libraries especially are about pooling knowledge, not gating it. This is propaganda for pooling that knowledge inside a service you have to pay to use, and instead of developers all using and improving the same codebase together, they have to spend money to rewrite the same code repeatedly. This is AI companies further trying to undercut open source because it’s free.
It seems like this was built years ago but only posted now. Why post it now? It doesn’t seem like it has changed much in 4 years so I can’t see that it matured or stabilized over that time. I am sorry for my ignorance of c build systems, this very well might be in high use already.
Either way, it looks useful and built by hand so good job! Looks great and I hope people find it useful!
I recently added a Ninja backend and a users guide and thought this might be helpful for a lot of people. It was pretty stable over the years. I have a few features on my todo list which I will implement as needed, and I recently completed my LeanDoc document language and migrated most of my specifications, which sparked further activities.
CarPlay is also a contract between mobile devs and automakers. It allows for things like displaying "current playing" on the dash, media buttons on the steering wheel that control apps, and turn by turn directions show on dash and HUD. A screen cast may be able to do this but not in a consistent dependable way.
Also no one is mentioning that maybe we should not encourage users to use 1000s of apps in their car? It would be irresponsible to easily allow users to watch youtube while driving. Keeping the set of apps usable through the car is a responsibility in automobiles that are already becoming too distracting as is.
Agreed, it keeps the parser fast as well because it is a lot more clear when the boolean statement ends and the code block begins. You either need parentheses, `then` or brackets around the block to make parsing clearly defined.
I think that allowing an if statement to return a value to deal with the ternary introduces a now concept to Lua and that is that the value on the final line of a block is a return value much like Ruby. This changes the logic of the entire language more than adding a ternary. I do prefer the if statement as it allows so much more emergent behaviour, but it does have more implications to consider.
I suppose, though I feel what most people in this thread are thinking of is updating the existing if statement to also work as an expression, which does have plenty of implications (not that I think they would be bad, just more of a change to the language than the feature designers were going for) including final returns. The example I took from Luau still keeps the if statement and the if-then-else expression as separate constructs. One problem is that the statement and expression versions look very similar despite having different semantics (expression version must only contain expressions in its branches, must have an `else` case, does not have `end`).
Of course there are differences between LuaJIT and Luau that I think influence their decisions on possible ternary expression features:
- Luau users are disproportionately beginners to programming that I believe would find the if-then-else expression syntax easier to learn; LuaJIT developers have a larger user base of professional devs wanting to make their code faster, and they will probably be more familiar with the `x ? y : z` style since it's used in plenty of other languages.
- Luau is a lot faster moving in its development than LuaJIT in terms of language features, the Luau team just wanted to move people to ternaries from `x and y or z` because it's easier to optimise in a normal interpreter; LuaJIT, with their JIT, I assume would be able to more easily implement optimisations for constructs like `x and y or z` despite its slight semantic differences (my assumption on why the change is being considered now rather than earlier).
Some of these things are already implemented in PUC Lua. I don't know why they are diverting from lua spec on other aspects though. Why not work together with the PUC Lua team to add some of these to both lua versions and work on bringing their functionality closer to each other
instead of further apart. You might as well just make a new language instead. New features will end up not being used in effort to keep lua scripts portable.
In effort to not pollute the github issue, and hopes that the authors read this thread, I will put some of my thoughts here. There are 3 main strengths of Lua: Embeddable, Fast, and Small(easy to learn). I worry some of these changes divert from the last, expanding the language into a more complicated language.
Here is a list of things already implemented in PUC Lua so can be considered safe to add:
● ~ a Bitwise negate
● a & b Bitwise and
● a | b Bitwise or
● a ~ b Bitwise Xor
● a << b Left-shift
● a >> b Logical right-shift
● a // b Floor divide
● break Break statement
Don't get me wrong, I love some of these quality of life changes like:
● Const keyword: changing const from `local a <const> = 42` to `const a = 42` is far better syntax. The bracketed syntax was never a good idea.
● nil-Coalescing and safe navigation are great additions as they are basically macros at the parsing stage.
● Compound assignment is also basically a macro at the parsing stage as well. Lua should already have this honestly.
● Ternary Operator: I *like* it and it will help the stumbling block of the `a and b or c` common pattern already in use. Though I think (like others have stated) the If/then/else syntax would be more inline with the language, similar to ruby and would enable far more emergent behaviour. However it does establish a new pattern that the last value in a block is a return value similar to ruby so I am conflicted about that.
● `continue` it is nicer than a goto and is helpful.
● String interpolation: I honestly don't love lua's concat operator `..` so honestly string interpolation would be a nice to have and a feature of many modern languages. However I do worry about it's effect on parsing performance, and complexity of the language.
● Underscores in numbers: *shrug*
These are great ideas for the language but I would want all lua versions to support them, not just JIT. These are things that I think are a distraction:
● The `and` `&&` and `or` `||`. This just goes in the wrong direction for lua. It is often confusing in ruby (especially because of precedence issues) but also lua is a wordy language. It has `do` `end` blocks instead of brackets. It adds ambiguity for no reason.
● Short form function syntax. Lua does not need this and I am not sure anyone asked for this. Why `a = |x| do ... end` is more helpful than just `a = function(x) ... end` is unclear and would love to hear more about why this is being considered.
● Named varargs: It may be nice, but there is no real reason to add this. If you wanted a name for your varargs you could do `local name = ...` or just use the `args` variable already available in every function.
● Switch/Match/Select Statements: An optimized if/else block works just as well and another expansion of a small language.
I asked for short form functions! Neovim has a ton of apis that accept functions as configuration. Having to write `function(x) return x > 3 end` is so much more annoying than `|x| -> x > 3`. I'd prefer just `|x| x > 3` but alas. I agree that a `|x| -> do ... end` lambda variant is redundant to normal anonymous functions though.
> Const keyword: changing const from `local a <const> = 42` to `const a = 42` is far better syntax. The bracketed syntax was never a good idea.
The bracketed syntax is an okay idea especially for <close>, adding close as a keyword would be a disaster given how common the word is. If anything, local should have been tossed away as a keyword and the bracketed syntax adopted completely
v <local const close>, v2 = io.open'file', false
g <global const> = 5
5.5 introduced global which makes better use of attributes as well. of course, I don't deny how great it would be to not type <> or local const since const would already imply a local
> string interpolation
Hisham already made this nice module https://github.com/hishamhm/f-strings Which I don't dare use, even if you don't have string interpolation. Of course, I don't care because I just have a table.format(tbl, "tbl.key is %{key}"), is it a little tedious? sure, but its just a gsub call.
> short form function syntax
I disagree with this, I've always wanted it and roll my eyes as I write/create a function, especially when you like to use lots of them like
str:gsub('%d+', (s){ tonumber(s)+1 })
> Named varargs: It may be nice, but there is no real reason to add this. If you wanted a name for your varargs you could do `local name = ...` or just use the `args` variable already available in every function.
You've made a mistake there
local name = ...
is
local name = ({...})[1]
In order to actually do this you need to
local name = table.pack(...)
If you will use a vararg, you will always have to do this, so why not just let it be handled in the parameter definition? its costless. AND lua5.5 already introduced this so it seems they liked it.
Quite frankly I would like the capability of treating ... as just an array like ...[1] but I haven't looked at the parser to see if its feasible or not.
> Switch/Match/Select Statements: An optimized if/else block works just as well and another expansion of a small language.
I don't disagree, but big table of functions is so ugly, switch statements would be nice
- Agreed on the bracketed attributes, the close attribute is very useful and devs would reach for the brackets more if they were like as you suggest.
- short form fns: you and another commenter have given me good examples. I’m still not sure they are worth the complexity but I understand the use better now.
- varargs true! Conceded!
reply