Sorry but I don't think you read any of the linked articles. Just one example of an anti-pattern that is very common and is undeniably harmful: Bad Revenue.
It comes down to deceiving or annoying your customers. E.g. making cancellation difficult or confusing, tricking the users into buying yearly subscription by showing them the monthly price of the yearly subscription (explicitly prohibited by Apple in mobile apps btw) and many others which can boost your revenue short-term but do a lot more harm in the long term, or eventually even kill your company.
These sales anti-patterns can work for bigger companies that are long past their growth stage and are now looking for ways to squeeze pennies out of every customer. Early stage or growth stage startups should not copy these practices: growth is a very fragile thing that can be destroyed by negative word of mouth easily.
One unexpected discovery that I have made while building an AI-based system: the LLM's are bad at designing prompts.
We tend to think that the AI has some sort of self-knowledge and should be good at designing prompts for itself but it's really not.
Been struggling with a task that heavily depended on prompts, ended up rewriting all my prompts from scratch in my own words, and it finally worked. Then every time I ask Claude to fix something in the prompts, it invariably makes it worse.
A very strange phenomenon that can probably be explained by the quality of prompt design advice that made it to the training dataset. Bottomline, all the prompt design advice that you can find on the internet is really not great.
Generally, facts over instructions. This has been Anthropic's recommendation too, in one of their recent blog posts.
Also the shorter the better, let the model figure out the rest. Overinstruction degrades intelligence. We tend to underestimate their capabilities, we overinstruct them and then complain about them being dumb.
True, tried it so many times and every time I come up with something myself though sometimes inspired by the AI's ideas.
Verifying trademarks and domain name availability is usually an additional step you need to ask it to perform. Trademark DB searches by the way are intentionally made difficult to scrape so most of the time it's a manual process anyway.
However, once you give it all the information (TM search results, domain name availability) it can help you with the judgement of how safe the name is from the legal perspective. With the obvious caveats, but still a good starting point if you are serious about the name.
> The result would be worse code, probably. Also probably still good enough.
And that's because the definition of "good enough" is drifting towards "crappy", has been for decades, now accelerated by the AI.
Was thinking the other day how the bars of quality for software pre-Internet was so much higher just because any small software shop only ever had one shot: ship your software on floppy disks, with practically no chance to patch and fix bugs later. People either like your 1.0 or they don't and that's your whole business story.
Then came the Internet, bug fix updates became so much easier, and with it came crappification and bugs-as-a-norm attitude.
> And that's because the definition of "good enough" is drifting towards "crappy", has been for decades, now accelerated by the AI.
Interestingly I have found the opposite in the software I write. LLMs make it so easy to get the basics in place that I spend the time on the details and polish.
Nothing so scientific. Im just having a lot of fun using the software I write with LLMs because I can easily add polish and build things I didnt have time for before.
This is all good to know, but funny how we are suddenly back to formal languages and commands. Aren't these things intelligent enough to figure these things out for us?
Exactly, and nothing will ever match the "prestige" of .com
.ai is also kind of cool right now but it will probably lose its appeal after some years when everything will become AI and the world will get tired of the term.
But .com is still at the top of the food chain. If you can survive for a few years, raise your series A/B, you will likely have enough money to acquire your sexy single-word .com name.
Yes to all that but still, my pet theory is that languages rise on one or two "killer features" that move the entire industry forward, and not the overall cuteness or lovability.
I can suggest a list of one killer feature per each popular language, i.e. things that these languages were the first to introduce and influence many successors:
C: extreme conciseness
C++: implicit destructors / RAII
Python: removed curly braces
Java: extreme portability
JavaScript: erm...
PHP: embedded in HTML by design
Rust: compile-time memory management
Swift: structured concurrency (pre-6 was probably just pure cuteness)
C is not "extremely concise". Lisp, and especially APL both predate C and are more concise. To me, the "killer feature" of C is UNIX, we can't really separate them, C won because UNIX won and vice versa. Other than that it is reasonably concise, reasonably portable and reasonably low level. The language itself doesn't have any "killer feature".
For Python, I think its killer feature, related to the removal of curly braces is that it is a dynamic language (like Perl) that forces you to write somewhat readable code. You have no choice but to indent correctly, and there is a strong "pythonic" ideal way of coding, the complete opposite of Perl's "more than one way to do it".
JavaScript killer feature is obviously its integration in browsers but it is also well designed for this task, with pretty good support for asynchronous programming.
Still, I don't think any of these languages were successful for their "killer features", more because of a combinations of many things. In many cases, they weren't even the first. For example, there are several langages that use indentation as syntax that predate Python. ( https://en.wikipedia.org/wiki/Off-side_rule )
C++ succeeded because it was Object Oriented, people didn't start talking about RAII as C++ killer feature until years later
python succeeded because it wasn't Perl's TMTOWTDI, everyone expected ruby to overtake python, but .. for some reason that never happened
swift succeeded because apple pushed it to replace objective c, that if you consider swift succeeded
anyway, i agree with your premise, languages need one key strategic advantage feature to succeed, but you just got it wrong on few of them .. and if i am wrong too, then the premise is weak, if we are not sure what the killer feature is, we then have no idea why the language succeeded
I don't think C++ succeeded because it was object-oriented. I think C++ was object-oriented because classes were an abstraction that could layer on top of C with fairly low overhead, giving it more expressive power without much mandatory cost to size or speed.
In other words, object-orientation was the means, not the end.
> python succeeded because it wasn't Perl's TMTOWTDI, everyone expected ruby to overtake python, but .. for some reason that never happened
Ruby allows (and to some extent encourages) unreasonable code.
It's not bad code (and in some cases extremely elegant), but it's code you can't reason about.
Being able to open any class (or object) and add new methods to it makes tracking how execution works extremely difficult.
The language allows for very undisciplined things to work - its great for the "scripting" and rapid prototyping - but unless you're going to throw it away the next day of having to maintain that code it starts weighing on the future speed of working.
Undisciplined code can be handled by making sure everyone on the team is disciplined in its use and documenting how things work... but that rarely reflects reality.
And so, you move to a language that enforces more discipline in how one uses it and is more reasonable in its execution.
Ruby felt like a better Javascript, but JS ran in the browser, and so had the constraint of the DOM...
Aka you have to be (more) disciplined within the constraints of the browser.
I'm not saying JS was good...
The lesson here being, complete freedom is fine, as long as you are also able and willing to implement a strategy to verify your operation, ruby on rails, js in the browser, python PEP or pythonic ways...
I came to ruby from the perl side. It was "here's a Redmine server, here's a feature request for one of the in house built plugins." I forget the specifics (it was 2011) ... but trick of the feature was to add a function to the object being created so that it would have the function some other module was expecting. And it worked...
Things like that made me give it the sideye for anything more than I could keep in my head at once... if I started needing to look at other files to determine if there was anything odd there... "can I create a function here in this parameter passed to me? What if someone else created a function of the same name before they passed it to me and expected it to remain?"
It can work... but it requires a bit more discipline than the developers I was working with had as a baseline (for that matter, a decade and a half later at a different job with a lower baseline and AI code - the idea of that terrifies me).
It's a "powerful" language, but I think it has too much power.
I like groovy for much the same reason that I liked perl and ruby (to an extent) - but it too is too powerful. It's great for writing scripts where it's a file or two or three... but if the "what does it do" gets too large to keep in my mind at once then it requires more discipline. I like to think that I have that discipline when working solo in groovy (and people will tell me I don't need to be that explicit in the objects... creating a class file rather than just shoving anonymously built objects into a hashmap), but that's how I can come back to old code more easily.
Initially, it provided a thin object-oriented abstraction over C. This solved many problems scaling large C projects. It set baseline expectations for languages that came later. Being a "thin object-oriented abstraction over C" has significant limits. By the 2000s, it was clear that C++ couldn't scale complexity in the way we needed it to. It was slowly dying.
C++ reinvented itself as a functional metaprogramming language starting with C++11, providing an even higher level of abstraction. Many deficiencies in the older language and systems languages generally were addressed. This was a huge success, creating a large resurgence in adoption and setting new expectations for what a systems language should be capable of. C++20 looks like a completely different (and much better) language than C++98.
I view C -> legacy C++ -> modern C++ as the evolution of a single language. Each was wildly successful on its own up to some level of complexity. Every time it runs into a practical limitations on scaling complexity, it adds a new layer of abstraction. As much as people complain about it, this strategy has clearly been successful.
This is an interesting take, although I'm not sure the legacy -> modern evolution is perhaps quite as significant as you make it out to be. Smart pointers and better std library constructs are absolutely welcome, metaprogramming is nice, but perhaps out of reach for many programmers (so not the "fun" or "successful" part of the language)...
If you were to compare the transformation with another major systems language, or a popular dynamic language, it doesn't feel like the evolution is quite as dramatic as is made out to be?
Rather, the staying power comes from elsewhere, and the language continues to modernize, perhaps at a slower pace than other contemporary languages experiencing similar staying power(s)...
C came with an OS. C++ came with compatibility with C and at the peak or near peak of OO hype. Javascript came with the browser making it probably the most widely available language platform. Swift came with Objective-C compatibility, an OS, and money (iOS app store customers spend more on apps than their Android counterparts).
Coming with a platform that is widely available or compatibility with an existing language on a platform was the killer feature for each.
Yeah, this is a more honest assessment than the others I've read here.
Of course them being ISO(like) standards with competing implementations/tools was also important for C, C++ and Java as the cost to use and learn them was higher in the days before free open source languages, free tutorials and help forums became so wide spread.
But yeah official platform support and big company backing are a big part of why these languages have stuck around compared to others.
To have a theory of success, you have to also be able to explain failure. Why did object-oriented C (aka C++) take off but object-oriented Pascal (aka Delphi) not, despite the fact that Pascal was as prevalent as C in those days? Why was Python able to overturn Perl's dominance in the scripting space, but Ruby was unable to do so? Why did Ada and Smalltalk never achieve significant dominance?
A lot of success does come down to being in the right place at the right time. JS was successful because it was the only available scripting language for the web (although MS pushed VBScript for a bit) when there was a concerted effort to kill off the Java and Flash plugins. C was successful because it was tied to the Unix OS, which happened to overtake other OSes for a variety of reasons.
I believe JavaScript's was running in the web where Java could not (iPhones) or was considered too heavyweight (no startup).
Then it became the true extremely portable language, because developers wanted a single language to write webapps in, and it was easier to get JavaScript running on their server than a new language running on every browser.
Javascript didn't need a plugin, unlike Java, and could directly alter the page contents. One of the first heavy uses was Google Maps, interactive JS-based applications took off at that point. Then with an army of web developers (meaning in browser), Node took off when it handed them a way to work on the backend in the same language.
The iPhone came out after JS heavy pages came into existence, and might have accelerated the end of Flash and Java applets but the trend was already there.
Let's be real here. JavaScript didn't take off because it was functional in the functional programming sense. It took off because it was built in and procedural. You didn't need to muck around with objects if you were a total noob. You'd just write your functions and call them with strings as parameters.
Javascript took off because it was your only option for a lot of things. Flash and Java tried, but both were always hit and miss as to who could use it. Everybody had javascript in their browser so you had no choice if you were to reach them but meet them where they were.
and despite all of its shortcomings, the ecosystem really grew. There are mainstream languages that to this day still can't match npm (looking at you, Python)
I like that theory, if I was going to counter it though, I'd say that I'm not sure those features match what language users talk about. For instance:
- C: Users often praise the simplicity of the language
- C++: Users often praise (not always praise?) the large feature set for a low level language
- Python: Folks talk a lot about "batteries included". Although in all honesty, I think having good interaction with other low-level languages is Python's secret feature.
- Java: Really leans in hard to object oriented programming
- JavaScript: Haha, you have to use it!
Not sure I'm really disagreeing with you though, but I think Java promoted its portability much more than it's ever been used (obviously there are cases like Spark which uses the JVM portability).
Swift: (reaon reason->) only Apple recommended language of choice for SwiftUI and iOS/macOS development.
Swift could be the worst language in the planet and people would still learn it. For considerable amount of time, its compiler used to timeout for many code-bases and people still gritted their teeth and learned it.
Except for PHP I don't think that's a very fitting list. C for example, is not really a concise language, not even for its time - APL is much more concise. C is rather verbose.
Likewise, Python is not the first language without braces - and it debuted before braces became the industry standard. I guess ISWIM or ABC are the first to have syntactic whitespace.
Really, you will always find an earlier example for a "killer feature", at least in an academic context - in the case of your list, usually in the 1960s, in the 1970s at the latest.
this is just survivorship bias. I bet you 1000 dollars that there exists hundred languages that are more useful and well thought than those languages you listed, but still nobody cared and it died.
I believe the reason lies entirely outside of the language itself.
let just say, the is a circle, a society (of programmer and related peopel) that decide that a language can be popular or not. if your language get picked, then it will be popular, if not, then good luck.
you can deduce easily what the criteria (to be picked) from the list of languages you mentioned:
1. if it does not come from US, good luck (ruby is an exception but it didn't sail until some americans decide to boost it)
2. if the language authors do not speech english well, good luck (I mean, sure if you advertise your language more more people will pick it)
3. if you satisfy 2 previous conditions, if you do not play along well with those people in the circle, then good luck (D is a good example of this)
4. even your programming language is dog shit, as long as you know the people in the circle, they will promote it for you. bonus point: if you allow the language to be directed as they want, then it will be extra smooth.
tl;dr: it is mostly politic how a programming language gets popular.
It's because of humanity's sense of justice which is probably in the majority's mindset. Can't back it up with data or research but I think the majority of any population would vote for measures like e.g. reducing the wealth gap. Hence "reality has a left wing bias".
I tried Kimi K3, Qwen3.6 35B A3B, GLM 5.2 and Qwen3.7 Plus, chosen arbitrarily from Chinese models I could access quickly. I used your prompt exactly, and all 4 managed to produce correct functions all with the correct name.
Interestingly, Kimi K3 wrote one in both C and Python, Qwen 3.6 chose Python, GLM 5.2 also chose Python, and Qwen3.7 decided to be an over-achiever and wrote functions in Python, C++, Java, and TypeScript. All correct and with the correct names.
My local Qwen3.6-35b-a3b model would not use the function name. It did the work though, while telling me the the slogan is against the One China principle. So for Qwen it seems to be baked into the model.
DeepSeek series are open weights models. Assuming you have enough compute at hands you can always download their weights from https://huggingface.co/deepseek-ai
You can find on Huggingface a huge number of Chinese open weights LLMs from which the censorship has been removed.
They typically contain in their names words like -abliterated or -uncensored.
For some of the recent bigger Chinese LLMs, it took a longer time until someone succeeded to remove the censorship, but eventually uncensored variants were published.
E.g. for Kimi 2.6 an uncensored variant appeared only a couple weeks ago.
It was a rhetorical question. OP is making it sound like the open weight models are fundamentally broken by being censored out of the box. This is a completely asinine take.
- The computer is plugged to an infinite source of unlimited power
This was big before the mobile era and is true to this day to an extent. Many mainstream languages created in the 1990s (I call them "the children of the 1990s") were designed with this fallacy plus the ones you listed as a basis: JavaScript, Python, Ruby, Java, etc.
Java is basically the "greenest" managed language out there, so not sure putting it into the same list for energy efficiency is warranted. Though of course energy efficiency is fundamentally linked to memory usage, not destructing/collecting dead objects will increase memory usage but increase efficiency.
Reading your link IMHO in today's world I would set a basic rule, if you're touching >20% of a Java codebase you should refactor to Rust. With AI-Native development practices it's worth the SDE time to refactor, replace the underlying subsytem and reduce your fleet by 50% or more.
Unless you are doing something very specific where rust is truly the best choice, I have to disagree.
Rust has overly strict locking (otherwise it couldn't determine safety) that makes certain concurrent algorithms harder to implement, its concurrency model is significantly more complex (for an absolutely good reason, it's a low-level language where the developer should be in control), meanwhile for many applications Java can just have you write ordinary blocking code and they will automagically turn into non-blocking.
For most domains Java has a richer "industry-strength" library ecosystem, and absolutely not even close observability tools. So not really sure what would one win for e.g. a typical backend service doing web and db requests.
JIT gives you almost native performance. AI rewriting tools give you none of the knowledge of running the thing in production. A couple of noticeable mishaps could cost more than halving your fleet saves.
It comes down to deceiving or annoying your customers. E.g. making cancellation difficult or confusing, tricking the users into buying yearly subscription by showing them the monthly price of the yearly subscription (explicitly prohibited by Apple in mobile apps btw) and many others which can boost your revenue short-term but do a lot more harm in the long term, or eventually even kill your company.
These sales anti-patterns can work for bigger companies that are long past their growth stage and are now looking for ways to squeeze pennies out of every customer. Early stage or growth stage startups should not copy these practices: growth is a very fragile thing that can be destroyed by negative word of mouth easily.