Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Imo, we should go in the other direction. Everything should be an own type. A url should be a URL type rather than a string. A persons's name should be a Name type rather than a string. Why? Because you can have handy functions appropriate for each type. A URL type could have functions like getting the separate paths or getting the query part. A Name type could have functions like getting the initials or represent it as a string in a culture specific way.
Another benefit would be that you couldn‘t assign a Name to a URL since they are different types. Eliminating a whole class of bugs.
Plus all the other benefits of type theory like provability. -
@Lensflare helper functions over strings
-
You have clearly vaporized more crack than I could possibly ever, therefore my deepest respect, first and foremost.
The strongest argument to be made against this is that the constant need to interpret values would add a sizable overhead, so not the best design for systems programming.
For a scripting language, though, it may be workable. The concept reminds me of implementing small DSLs in perl, a sin that I have undeniably committed without shame.
Hail freebasin'. -
@Liebranca quote from the rant:
Performance will be lacking compared to languages with static types, but performance is not a priority here — this is the language for code monkeys and their AI counterparts. It should only be used for making trivial client-server prototype apps that could've been replaced by Excel if only people knew how to use it, at passable quality, that work reasonably fast on modern hardware. -
@Liebranca we're not making software for smark, knowledgeable people. We make software for the masses.
-
@kiki "We make software for the masses."
I thought that was Python though? I like Python, but it is kinda like legos. -
@kiki me big smark deblooper! me build scalable colonoscopy machine soffwurz in rooster-walrus!
-
@Liebranca lmao smark
-
@retoor and rightfully so. One of the most important properties of code is clarity and unambiguity of intent.
With string + int, the reader of the code might wonder if the author intended to concatenate to "33" or to add to 6 or something else. And it’s not immediately clear what this particular language will decide to do.
So best case is it works but you don‘t know until you test it.
Worst case it’s a bug because the author either assumed the wrong behavior of the language or made a mistake in his intent.
When the language forbids to do this and demands to cast the types explicitly before adding them with +, all of the problems go away.
we don't really need data types. By default, everything should be string. When you do addition, when the string has nothing but digits, commas and periods, they should be parsed added as numbers. Else, they should be concatenated. If that string-number formatting doesn't match any conventional formatting of any locale, it's a string. Same number-inferring behavior should be implemented when comparing things. There should be no type casting because there is just one type, so every comparison is type-exact. "true" and "false" are special strings that won't throw an error during comparison. Comparing two strings using less, more, less than or equal and more than or equal always throw an error.
Dates are ISO strings. Every other thing is not a date.
We basically sieve the data starting with the strictest conditions down to more forgiving conditions, then down to no conditions at all where it will be interpreted as just string. ISO date requires a very specific formatting, so we should check that first. Then, let's check for a formatted number. Then, a boolean. If nothing clicked, it's a string.
Oh, and every string is automatically trimmed, so it can't start or end with any kind of space.
No classes, no procedures, no constants, no switch operator. Also, no methods, just a lot of helper functions.
Performance will be lacking compared to languages with static types, but performance is not a priority here — this is the language for code monkeys and their AI counterparts. It should only be used for making trivial client-server prototype apps that could've been replaced by Excel if only people knew how to use it, at passable quality, that work reasonably fast on modern hardware.
Those apps will be deprecated because the company went out of business/because the project was proven to not be financially viable in several months anyway.
UI should be rendered not using a webview, but using a lightweight cross-platform UI engine written in a proper language like C++. There should be no semantic tags — every UI element acts like a div would. Everything is measured in pixels and milliseconds. All colors are #rrggbbaa. All vector graphics are SVG, all raster graphics are AVIF. All sounds are Opus. All videos are AV1. All UIs are reactive, Vue style, e.g. you change a variable and the UI updates itself in the right way every time.
Add some junior devs paired with GPT-4.5 or any super-expensive LLM, sprinkle with some Extreme Go-Horse management style (https://hackernoon.com/you-might-be...), and boom, we recreated Zergs but in the tech space. Let's solve software by brute force.
random