Adding sugar to wine is considered a great offense, and is not only illegal in France, but a disagrace. Still, some winemaker wake up in the middle of the night to do it in secret because it's hard to get a sweet taste or more alcohol naturally. Therefor, the anti-freeze workaround is not surprising.
It was a simplification on my part. If you want to be precise, then chaptalisation (the process of regulating alcohol quantity using sugar) is illegal in south of France vineyards, forbidden everywhwere when mixed with acidification processes, and allowed but under very strict conditions otherwise in "septentrionales" vineyards (which I have no idea how to translate in English).
It's the default in Python, and it's more helpful that not, so I would say it's a good design decision. But "always" is a dangerous word in engineering, and in this case, definitly not warranted.
Case in point, last week I worked with list ofdates, and I needed the last date to bracket my sliding windows as a time period cleanly.
That's why we have languages with functions now, because people didn't want to manually do a register dance in assembly.
That's why we have name spaces, because naming conventions only take you so far.
That's why we have map and filter (or equivalent) because that's what most loops are doing anyway.
Generation after generation, we discover that we all use common abstractions. We name them design patterns, then we integrate them in the language, and now they are primitives.
And the languages grow, grow, bigger and bigger. But they are better.
More productive. Less error prone. And code bases become standardized, simple problems have known solutions, jumping to a new project doesn't mean relearning the entire paradigm of the system in place.
Small languages either become big, or are replaced by things that are big, for the same reason most people prefer a car to a horse to go shopping.
Not that horse ridding will totally disapear, but it will stay in their optimal niche, they are not "the future".
SQL persists because it's an interchange format, not just a programming language. It's one of the few programming languages you'll see embedded in other languages - and generating SQL from other languages is a common source of security bugs. You can't upgrade away from SQL without changing both ends of that connection.
You can write large programs in SQL, but it's generally considered good practice not to.
(I feel I ought to mention LINQ here, not to make any specific point but just to fanboy about it)
same, and in fact, despite using C# since before LINQ even existed, I don't even know how to write the sugar candy version of it.
Part of that is me coming from C++ and its algorithm header and the other part is that the code is just easier to read and understand than the sugar candy version (to me, atleast).
Somewhat pedantic argument: SQL is kinda dead. Sure, modern databases use upgraded dialects of it, but they are custom to each database and often incompatible with plain SQL. There are even many cases where modern databases don't support even standardized SQL constructs.
The easiest example of where databases and SQL part ways: UPSERT. It doesn't exist in standard SQL.
Then let me address the forest. Modern DBs offer SQL as an on-ramp for the most common DML and querying. This further entrenches it as a data language and why SQL just won't die.
There are always more proprietary methods where one needs them. That doesn't mean SQL is dying, it means SQL will likely grow to include some of those too.
> Small languages either become big, or are replaced by things that are big, for the same reason most people prefer a car to a horse to go shopping.
So why are shell languages still around? Why are they not replaced by C#, C++, Java or another big (=general purpose) language?
I find your horse->car comparison more akin to the sh->bash->zsh transition. Zsh is not as small as sh, but still it is in the small league is you ask me.
Small does not mean w/o functions, without NS, without map/filter: it means "not general purpose".
Shell languages are a very good example, because they have been replaced mostly by bigger languages. First by perl, then by python.
Now a day, most people don't write bash if it must be more than a few lines: it fits niche perfectly, like horse ridding.
But you are not going to do website with bash anymore, server swarm deployment with powershell or build your encoding pipeline in fish. Tasks that we used to do using those small languages, until we found out that we prefer a car to do shopping.
I do this routinely with powershell. Powershell is not bash or fish, its highly usuable in all situations except those that require greatest performance and even then there are solutions for various types of problems.
I'd say you're in the extreme minority then. I'm not a bash hacker but I usually end up writing a little script for myself at least once a month. Even just doing `command && command` is technically using a shell language
I said I write custom scripts about once a month. I use bash literally every day. But I also wasn't arguing the future of programming languages. The parent here said that shell languages aren't being used
Still alive and quite well. In fact, as more and more programs are written, they become more and more useful. We're already well into an era where programming can be nearly entirely ignored in favor of merely scripting new behavior out of the interactions between existing programs.
Shell languages have "must be easy to type in execution order" and "must integrate with random programs on the filesystem" as an overriding consideration. You're not going to get that with Java.
gawk compiled via webassembly to allow for running in browser allows 'modern' gui input / output beyond the command line interface while still retaining the ability to be just a cli program.
The irony of your horse analogy is that a horse is more general purpose than a car. A horse can travel along train tracks, roads, sidewalks, and hiking trails.
There’s two things that the article mentions that your omni-language has massive problems with:
1.) Performance. For example a run-time for a user-friendly little language that maps HTTP requests to SQL queries can be much faster than a language that does the same thing by plugging user-friendly APIs together. A custom run-time can parse an HTTP request string directly into SQLite op code while the JS developer is writing glue code that takes orders of magnitude more memory and CPU time.
2.) Static analysis. This means tools that are better at finding bugs, finding optimizations, visualizing structure, etc.
Both of these things are theoretically true, but only if the little language has enough resources behind it to optimize and build enough tooling. A big language is much more likely to have those resources because the target market is big enough to justify it. A niche little language will likely never get that kind of mass behind it, so the tools will be lacking and the runtime won't be optimized.
Big general purpose languages don’t have the capability for certain kinds of performance improvements or static analysis so the market size isn’t a factor.
My point isn't that the big languages can do everything that a little language could theoretically do, it's that the little languages won't have the resources to pull them off, nor will they have the resources to even do what the big languages do.
Proper debugging, syntax highlighting, language servers, security audits. These are things that engineers in the real world expect a language to have, and each little language would have to reinvent each of them. In contrast, a library can piggyback off of the tooling provided in the host language.
So even if a language can deliver on the performance and static analysis that it promises (which few will), it cannot reach adoption because it cannot provide the infrastructure needed.
(That doesn't need even get into the onboarding concerns that I and others have raised about having a codebase that is strung together from a dozen tiny languages.)
Proper debugging, syntax highlighting, language servers, security audits. These are things that engineers in the real world expect a language to have, and each little language would have to reinvent each of them.
I don’t always see this as the case and this might be a very fruitful area for research. What I mean is, much like how we have tools like bison, antlr, and the k framework, I could easily see this notion extending to language servers, etc.
As for onboarding, well, who are we onboarding? New software engineers working on a general purpose language or new operations members working on a DSL?
I remember a time when CSS and HTML had yet to be consumed by a general purpose language and the onboarding for new web designers was significantly easier.
> I don’t always see this as the case and this might be a very fruitful area for research. What I mean is, much like how we have tools like bison, antlr, and the k framework, I could easily see this notion extending to language servers, etc.
Yeah, I could see this happening, to a point. I'm not convinced it will happen, because what would be the impetus?
> I remember a time when CSS and HTML had yet to be consumed by a general purpose language and the onboarding for new web designers was significantly easier.
So do I. I had a friend whose dad wanted to start building web pages for a living, right at the moment when that job was starting to vanish.
At least two factors were involved in that shift:
1. More and more companies wanted web applications, not simple web sites. A functional web app requires engineering effort or it falls apart, whereas a simple web site just requires making things look right. Once these companies had engineers for a web app, it was simpler just to pay them to build out a marketing page than to hire that out (even if hiring it out would have been cheaper).
2. WordPress was becoming more and more approachable, and others like SquareSpace stepped in to make it even easier for a non-technical person to build a website. Companies that didn't need engineers for an app realized that they could do a good enough job for their needs by just using these tools in-house.
I suspect this is the fate of any little language that successfully eliminates the need for engineers: if we can take a piece of a domain and describe it in a DSL that is streamlined enough for no-effort onboarding, it won't take very long for the DSL to be made redundant by GUI tools that are even easier to use.
At that point, the DSL either goes away entirely or it morphs into something bigger to meet more complex needs (as HTML/CSS/JS did).
(This doesn't apply to DSLs like Regex and SQL that are designed for use by engineers, but then we're back to the question of whether an external DSL is pulling its weight relative to an equivalent library.)
That there are many issues with general purpose programming languages such as those outlined by the author in the article?
> I suspect this is the fate of any little language that successfully eliminates the need for engineers: if we can take a piece of a domain and describe it in a DSL that is streamlined enough for no-effort onboarding, it won't take very long for the DSL to be made redundant by GUI tools that are even easier to use.
That seems ideal! Domain-specific languages have always benefited from GUI tooling alongside anything that is less clunky as textual representation.
It is a fruitful area for research! Truffle is an example of the sort of framework you mean. Implement a parser+interpreter using Truffle and you get JIT compilation, GC, debugging, profiling and more stuff for free on top of the JVM.
I don’t want to spend all day playing human debugger because your little language doesn’t support debugging.
I’m not here to tell you how very clever you are for reinventing the wheel. I have my own shot to get done and that’s easier when we make a smaller language out of our general purpose language by agreeing to style guidelines, instead of avoiding solving social problems with technology by creating your own game to change the rules.
When everyone in your group expects the rest of the team to commit
10% of our attention to their tool or module, that doesn’t scale. If we go more than 50% total our capacity to solve problems becomes hamstrung.
If you work someplace where new devs are useless for a year, you’ve likely already got the snowflake disease.
> People have been making this argument since the 80s and possibly even earlier. My experience is often the opposite. Little languages are usually far, far harder than (mis-)using "big" languages for small tasks.
From the top level comment.
It’s also the primary failure mode for DSLs. There’s never any thought for tracing and debugging, and so it becomes a peaen to the primary author(‘s ego).
Once you no longer have impostor syndrome it gets much harder to play along with these ego trips. It’s not that I’m too dumb to understand your DSL, it’s that you’re a fool who thinks writing your own language is the pinnacle of success. It’s very rare for it to better than a decent API and you’re thinking about yourself, not your coworkers.
That’s why everyone always mentions SQL. It’s the exception to the rule, not an example of when DSLs can be good. Remember XSLT. Remember a dozen other failed DSLs. Per decade. Forever and ever.
So every new language is written be a fool on an ego trip? Or are you calling me the fool?
I'm having a very hard time separating what seems to be a painful personal experience from a productive conversation about the future of programming languages.
- Hard to onboard new hires
- Code breaks because of lack of understanding of dependencies
- Code changes become harder to manage
Anyone who finds these problems improved by a DSL isn’t spending time looking at what is actually making life hard for their coworkers, and therefore arrogance.
What helps me with those problems is tool selection. Picking community supported tools that fight some of these problems by allowing me to hire people who already know part of our system, and who can use a wider community as a knowledge base instead of just internal folks who have run off to work on other interesting things and don’t have the time anymore for something cool they did three years ago.
A veterinarian explained part of the dynamic to me quite some time ago: it’s better for your emotional relationship with your pet if a stranger does an uncomfortable procedure rather than you. If we use a tool with poor support at least we can bond over it as a team. If it’s Steve’s baby and he’s terrible at support that animosity turns inward, which is not just a problem, it’s the beginning of the end.
I think I figured out the issue in this discussion. The article is actually about general purpose vs domain specific and not really about big and little… and unfortunately since most “DSLs” are APIs written for in general purpose languages the author resorted to using the term “little language”.
2.) SQL is not a general purpose programming language and is used as an example of a little language by the author.
I can clearly imagine a future where instead of a few large general purpose languages we have a multitude of niche languages that have better performance characteristics, better tooling and smaller individual learning curves.
I don't think it's that weird, there not a lot of differences between people at the top or at the bottom.
It's the fact that they were idealized that makes this dip into their intimacy so strange.
But basically, those communications look a lot like ones that I would have with my own friends. And when I was a students, we were careful about spending 10 euros. Now, we have casual chats about buying a sauna for the garden, and if you think about it, it would sound crazy to someone making minimum wage.
If I had billions, I would talk as casually about huge amounts for actions with big consequences, because I'm still ...me. And I would still make jokes like "you have my sword" since we quote LOTR for fun, not because of social status. What? You thougth billionaires were taking all their texts seriously?
Also, calling people out for making mistake that cost you is kinda what everybody sane does. And apologizing to people when you made a mistake is not being submissive, it's being decent. Again, it reads like text I would send myself.
All in all, it seems pretty standard human behavior to me.
Now you may feel shocked that regular humans have so much power, but remember:
- a lot of luck is involved
- some skills like managing stress or being persistent may matter more than a lot others and those people may have much more than the average person
- this is by design in our system, the problem therefore is not that humans are humans, but that our system promote profiles that you don't think deserve it
- nevertheless, managing tesla or spacex is not something most people would succeed at, so there is probably some human traits those texts are not showing that make them capable of doing billions of dollars of operations
While it's fair to point out so many of the similarities between the people at the top and the bottom ... there are also differences. Notably, Musk is an outlier in many ways. The vast, vast majority of CEO's are highly conscientious at least in civil terms. They are 'restrained' if anything.
Again, even if they have some qualities that make them different in order to achieve big things, I would expect a Gauss curve to represent most traits distribution at the top like at the bottom. While most people show restrain, a few will be exhuberant, no matter the sample.
It's interesting that you start your post by demythifying these people only to close it by rebuilding the myth again. It's like we can't accept they are just like us posting on HN.
There is nothing mythical as having qualities that others don't have, and any context or system have a local maximum, which optimize for a certain kind of outcome.
My qualities would have me dead 200 years ago, but make me earn money and social status in 2022. It's not that I'm amazing, it's just the current context is very favorable to those qualities. So it's just a lot of luck, and being fit for certains things that happen to be advantagious in your environnement.
The myth is that the process is just and fair, according to some people moral standard. The universe doesn't care.
> not because of social status. What? You thougth billionaires were taking all their texts seriously?
And it’s mind blowing to me that money can’t buy a better iPhone, they all have to deal with fiddling with the cursor on HN, even princes in the Middle-East, no matter the height of the tower they’re at the top of, they use the same apps as us.
J is for complex numbers. While math.sqrt(-1) raises an exception, cmath.sqrt(-1) returns 1j.
There is not distinction between values and references in python, everything is a reference. In fact, primitive like numbers are big struct objects in cpython, you cannot just manipulate the raw numbers.
The difference will rather wether you can modify an object or not. You cannot modify numbers, as they are immutable. Any increment will produce a new object. But you can modify a list. This gives the feeling numbers are passed as values and list are passed as references.
Someone on a forum I frequent lost their (90 year old) father this morning. I never know what to say in those situations so I tend to hide for a few days.
I guess posting that screenshot wouldn't be the best move...
It wouldn't. But not because it's offensive. It is making a joke about the sympathizer's awkwardness, which is making it about yourself. A straightforward sorry for your loss is always best.
But he didn't published anything, that's what so great about Snowden's story. He shared documents with journalists and let them chose if it was worth publishing, and moral to do so. He worked in the way the system was supposed to work.
You don't need some special government certification or corporate media job to be a journalist, do you? And why should 'responsible journalists' be the only ones who get to look at spuriously classified documents? We all know that over-classification with the goal of hiding corruption or incompetence is very common.
A journalist may need a reputation to be taken as a reliable source of information... but I don't believe WikiLeaks has had to retract any documents as fake, unlike say, the New York Times on the claims of Iraqi WMDs, or dozens of other examples over the years by 'leading corporate media outlets'.
Are you replying to the right comment? I have no idea what this is supposed to be an answer to or a comment on, and I have no idea what system you think is working, or who you think has the authority to assign journalists a "purpose."
The way the system is supposed to work is a desperate run from US authorities, ending up trapped in a country that the US is hostile to? Sounds like Snowden and Assange did it the same way.
If only there were swarms of self replicating autonomous systems that can heal, recharge and defend themselves without input and adapt to new situations, while being stress tested for free for millions of years.
But I'm dreaming, certainly if it would have existed humans would have tried to leverage them a long time ago.
Snark aside, as useful as the birds and the bees are, they've got their own goals, and those goals aren't always aligned with ours — hence the use of pesticides and insecticides, or indeed scarecrows, in the first place.
