Gąska is a tart savour and wants to give floating jobs to Javascript

[cvi]

@boomzilla said in Gąska is a tart savour and wants to give floating jobs to Javascript:

@cvi said in Gąska is a tart savour and wants to give floating jobs to Javascript:

Either way, my observation predates the brace-initialization syntax from C++11.

What a coincidence. So does my compiler!

Do we have demographics for WTDWTF? Like, how many percent of the people hanging around here are younger than your compiler?

[boomzilla]

@cvi said in Gąska is a tart savour and wants to give floating jobs to Javascript:

@boomzilla said in Gąska is a tart savour and wants to give floating jobs to Javascript:

@cvi said in Gąska is a tart savour and wants to give floating jobs to Javascript:

Either way, my observation predates the brace-initialization syntax from C++11.

What a coincidence. So does my compiler!

Do we have demographics for WTDWTF? Like, how many percent of the people hanging around here are younger than your compiler?

Probably not many. We're currently on RHEL6 (with plans to upgrade to RHEL7 Real Soon Now™!). That means g++ 4.4.7, which was technically released in 2012, but C++11 support didn't start until g++ 4.7, I think.

Not that I'm going to go back and rewrite my code when we upgrade. Most of it was written while we were on RHEL5 and the key commercial libraries we use are from RHEL4 days (they actually have rhel4 in the file names).

[Gąska]

@cvi said in Gąska is a tart savour and wants to give floating jobs to Javascript:

@Gąska said in Gąska is a tart savour and wants to give floating jobs to Javascript:

Being context-sensitive prevents you from doing lexical analysis before any sort of semantic analysis. You HAVE to turn a type declaration into an information for your parser that there is such type with such name in such scope as soon as possible, or you'll be unable to correctly parse the rest of the file. It basically forces you to write spaghetti.

Well, this is exactly what the a*b example was demonstrating, no? As said, with a good parser generator that seems to be easy.

Well, have you actually tried to make a parser generator work with context-sensitive grammar? Make the parser spit out different AST based on information obtained from parsing AND SEMANTICALLY PROCESSING previous code? Yes, it's technically possible. But so is writing everything by hand, and it's arguable which one is less work - because at the end of the day, your "generated" grammar is still going to depend on SEMANTIC analysis. And that means not only a lot of spaghetti, but also that your semantic analysis will be working with incomplete inputs (which, BTW, is the main reason why everything in C has to be forward-declared; unfortunately, class members in C++ don't have to).

Well, my observations predating C++11 were such that I tripped over the most vexing parse at least once a month. Maybe you didn't pass default-constructed parameters to stack-allocated objects as often as I did?

Would the language be better if it didn't exist? Yeah. Are there other more pressing issues. Definitively.

Such as generally awful state of IDE-like tooling. I mean, it's mostly solved by now, but it was a big concern not so long ago. And simpler grammar would definitely make the process much faster.

10 is a large number. Are you able to list 10 features of, say, Java (or some other language of choice) that more important than "it's relatively easy to develop code analysis and transformation tools for it because of context-free grammar"?

Here's a random list for Lua. It has more than 10 items. (It may even have a context free grammar, but whatever.)

A lazy way out, eh? You didn't even read it yourself before linking it here, am I right? Okay, whatever, let's take a look:

Long boring nitpicking hidden for reader's comfort

simple
efficient
portable
extensible
adaptable to a broad range of applications

That's not features, that's opinions.

Lua is an extension programming language

That's not a feature either. I'm not entirely sure what it is, though. A goal?

Suitable for use as an embedded language within a host application
Cross Platform Support

Okay, that's 2.

Implemented in ANSI C

Implementation detail.

Lightweight core occupies just 60k and executable footprint of just 140k

Easy to use conventional scripting language

Opinion.

Dynamic datatypes
Powerful builtin support for text processing
Interpreted bytecode compilation for fast and efficient execution

Stack based virtual machine model

Implementation detail.

Support for procedural, object oriented, functional and datadriven programming
Supports coercion

freeform syntax

What does that even mean?

lettercase sensitive

...Well, okay, that makes 9. But is it really more important feature than "easy to manipulate programmatically"?

keywords

...No, that's too much. I'm not counting this.

---

So anyway. If you include the really really trivial stuff, yes, there's about 10 features on that list, and yes, some of them are pretty important. But I hope you can see why I don't exactly agree with your point.

[cvi]

@Gąska said in Gąska is a tart savour and wants to give floating jobs to Javascript:

Well, have you actually tried to make a parser generator work with context-sensitive grammar?

I mean, yes. Here's a small context sensitive parser in PEGTL for the a * b example that everybody's been nagging about.

Quick'n dirty PEGTL parser

#include <tao/pegtl.hpp>

#include <string>
#include <iostream>
#include <unordered_set>

#include <cstdio>

namespace 
{
	using StringSet_ = std::unordered_set<std::string>;
	
	struct Context_
	{
		std::unordered_set<std::string> types;
		std::unordered_set<std::string> variables;
	};

	namespace grammar
	{
		using namespace tao::TAO_PEGTL_NAMESPACE;

		// Grammar
		template< StringSet_ Context_::*tSet >
		struct KnownIdentifier : ascii::identifier 
		{};

		template< StringSet_ Context_::*tSet >
		struct NewIdentifier : ascii::identifier 
		{};

		struct Declaration : seq<
			KnownIdentifier< &Context_::types >,
			star<space>,
			opt< one< '*' >, star<space> >,
			NewIdentifier< &Context_::variables >
		> {};
		struct Multiplication : seq<
			KnownIdentifier< &Context_::variables >,
			star<space>,
			one< '*' >, 
			star<space>,
			KnownIdentifier< &Context_::variables >
		> {};

		struct Grammar : until< eof, seq<
			star<space>,
			sor<
				seq< 
					TAO_PEGTL_STRING( "type" ),
					plus<space>,
					NewIdentifier< &Context_::types >
				>,
				Declaration,
				Multiplication
			>,
			one< ';' >
		> > {};

		// Actions
		template< typename tRule >
		struct Action : nothing<tRule>
		{};

		template< StringSet_ Context_::*tSet > 
		struct Action< KnownIdentifier<tSet> >
		{
			template< typename tInput, typename tContext >
			static bool apply( tInput const& aIn, tContext const& aContext )
			{
				auto const& set = aContext.*tSet;
				return !!set.count( aIn.string() );
			}
		};
		template< StringSet_ Context_::*tSet > 
		struct Action< NewIdentifier<tSet> >
		{
			template< typename tInput, typename tContext >
			static void apply( tInput const& aIn, tContext& aContext )
			{
				auto& set = aContext.*tSet;
				set.emplace( aIn.string() );
			}
		};

		template<> struct Action< Declaration >
		{
			static void apply0( Context_ const& ) noexcept
			{
				std::printf( "Declaration!\n" );
			};
		};
		template<> struct Action< Multiplication >
		{
			static void apply0( Context_ const& ) noexcept
			{
				std::printf( "Multiplication!\n" );
			};
		};
	}
}

int main()
{
	namespace pegtl = tao::TAO_PEGTL_NAMESPACE;

	pegtl::istream_input<> in( std::cin, 4*1024, "std::cin" );

	Context_ ctx;
	pegtl::parse< pegtl::must<grammar::Grammar>, grammar::Action >( in, ctx );

	return 0;
}

 
It handles a mini-language that supports the following:

• type identifier; -- introduce a type called "identifier"
• identifierA identifierB; -- declare a variable "identifierA" with type "indentifierB". identifierB must have been introduced previously using "type ..:";
• identifierA * identifierB; -- this is either a multiplication if both identifiers were declared as variables, or a declaration of "identifierB" if the first identifier has been introduced using "type ...", and an error otherwise.

(I don't check for declaring a variable that is already declared as a type, although doing so would be trivial. Declarations take priority.)

Example

type a;
a * b;   // Outputs "Declaration!"
a * c;   // Outputs "Declaration!"
b * c;   // Outputs "Multiplication!"
b * a;   // Error. "parse error matching ..."

 

Long boring nitpicking hidden for reader's comfort
<snip />
S o anyway. If you include the really really trivial stuff, yes, there's about 10 features on that list, and yes, some of them are pretty important. But I hope you can see why I don't exactly agree with your point.

But, I can play the same game:

Grammar is context-free

Implementation detail. Which is roughly what I stated earlier.

[Gąska]

@cvi said in Gąska is a tart savour and wants to give floating jobs to Javascript:

But, I can play the same game:

Grammar is context-free

Implementation detail.

It's not. The grammar is the crucial part of the language's public interface. Being context-free is an important detail that opens a whole world of ready-made transformation algorithms to use - much like whether a given function is pure. Implementation detail is something that has zero impact on the correctness of the result of each and every operation you can think of.

[Gąska]

@cvi in other words - saying being context-free is implementation detail is like saying constexpr specifier doesn't belong in function declaration.

[cvi]

@Gąska said in Gąska is a tart savour and wants to give floating jobs to Javascript:

It's not. The grammar is the crucial part of the language's public interface. Being context-free is an important detail that opens a whole world of ready-made transformation algorithms to use - much like whether a given function is pure.

I could make a similar argument about the "stack-based virtual machine model".

Implementation detail is something that has zero impact on the correctness of the result of each and every operation you can think of.

By that definition, as an end-user of a language, the type of grammar really is an implementation detail. From that perspective, it has zero impact on anything that I would be doing with the language.

[Gąska]

@cvi said in Gąska is a tart savour and wants to give floating jobs to Javascript:

@Gąska said in Gąska is a tart savour and wants to give floating jobs to Javascript:

It's not. The grammar is the crucial part of the language's public interface. Being context-free is an important detail that opens a whole world of ready-made transformation algorithms to use - much like whether a given function is pure.

I could make a similar argument about the "stack-based virtual machine model".

So make it. What does VM being stack-based allow you to do that would be impossible on non-stack-based VM (whatever that might be)?

BTW, it's funny you picked that particular point, since it was clearly written by someone who knows nothing about Lua's implementation - otherwise they'd know it's actually register-based, not stack-based.

Implementation detail is something that has zero impact on the correctness of the result of each and every operation you can think of.

By that definition, as an end-user of a language, the type of grammar really is an implementation detail.

It would be, if not for the fact that the grammar itself is publicly exposed, and from this public interface alone you can derive all by yourself that it's context-free. It's similar to having your function's implementation published in your documentation verbatim - making it part of the public contract that this particular function will always have this same implementation forever and ever. Let's say it's how you specified abs(). I don't need you to tell me it's pure to know it's pure if I can just look at the code (and know it'll never change because you promised it'll never change).

[cvi]

@Gąska said in Gąska is a tart savour and wants to give floating jobs to Javascript:

BTW, it's funny you picked that particular point, since it was clearly written by someone who knows nothing about Lua's implementation - otherwise they'd know it's actually register-based, not stack-based.

TIL. Apparently it changed in Lua 5.0. Neat, learned something from this discussion.

FWIW, the stack-based design is/was a huge influence on the design of the API that you use when embedding Lua. The API still exposes the stack-based interaction model.

It would be, if not for the fact that the grammar itself is publicly exposed, and from this public interface alone you can derive all by yourself that it's context-free. [...]

I don't know what to make of your analogies, they are not helping me understand your point.

I know the difference between a context free and a context sensitive grammar. I still don't get why I would care as an end-user. As an end-user, I'm not writing parsers for it. (And even if I were, I can deal with context sensitivity - I can express that concisely in my grammars. Whatever limitations/problems I encounter, they are elsewhere.)

At least, @Mason-Wheeler made one of his point very clear - context-free grammars are supposedly simpler to understand for humans. I don't necessarily think that's untrue, I just think there are way more significant contributors to whether or not a language is easy to understand.

The argument that I'm presenting here is the same. Yes, context free vs context sensitive makes a difference in the language. (One is a superset of the other, so clearly one can express stuff that the other can't.) It's just that the fact that a language has a context-free grammar is so far down the priorities that it just doesn't matter. For example - the fact that Lua is implemented in ANSI C (I guess that's at least still true these days) is more important to me than what class of grammar the language uses.

But perhaps this is something where we have to agree to disagree.

[Gąska]

@cvi said in Gąska is a tart savour and wants to give floating jobs to Javascript:

I know the difference between a context free and a context sensitive grammar. I still don't get why I would care as an end-user.

End user is just end user. Like everywhere else in IT, the end user only sees the tip of the iceberg - there's much more going on behind the scenes. Even though it's all hidden, it's still extremely important for some people - including users other than end users, such as plugin developers - or, in case of programming languages, developers of support tools. Paradoxically, the needs of non-end users might sometimes be more important than those of end users - because better support tools matter more for end users than better core language. D is amazing language, but there are few notable projects using it because the ecosystem is very weak. PHP is abysmal language, but many amazing things were made in it because the ecosystem is so robust.

As a user of a language, you don't get any direct benefit from context-free grammar - but indirectly you get enormous gains from it, because easier tool development means better tools. So as a language designer, even though the category of your grammar feels like academic navel gazing, not making it context-free is arguably the single biggest mistake you could possibly make, as it basically kills any chance of getting wide audience due to shitty IDE support. The world isn't going to put up with another C++ - times have changed and walking over burning coals isn't the expected user experience of programming anymore.

[HardwareGeek]

@cvi said in Gąska is a tart savour and wants to give floating jobs to Javascript:

If you list the 10 most important features of a language, and having a context-free grammar makes that top 10, then that language is uninteresting/not really worth perusing further and IME probably sucks in other regards.

@cvi said in Gąska is a tart savour and wants to give floating jobs to Javascript:

context-free grammars are supposedly simpler to understand for humans.

Brain-Flack (a derivative of brainfuck) has a context-free grammar. Just sayin'.

[HardwareGeek]

This post is deleted!

[cvi]

@levicki said in Gąska is a tart savour and wants to give floating jobs to Javascript:

Careful saying that, you don't want to get the downvotes like I did for pointing out the obvious.

Oh, think it would trigger downvotes if I told people that they should just git gud and get a proper parser generator framework, i.e. one that handles context-sensitive grammars?

[Gąska]

@levicki said in Gąska is a tart savour and wants to give floating jobs to Javascript:

I guess someone is

My bet is on the guy who blocked my posts but still comments on what I say.

[topspin]

@Gąska said in Gąska is a tart savour and wants to give floating jobs to Javascript:

@levicki said in Gąska is a tart savour and wants to give floating jobs to Javascript:

I guess someone is

My bet is on the guy who blocked my posts but still comments on what I say.

You saying he's downvoting himself? Is this some kind of boomzilla joke?

[dkf]

@Gąska said in Gąska is a tart savour and wants to give floating jobs to Javascript:

Being context-free is an important detail that opens a whole world of ready-made transformation algorithms to use

You're overselling it. Context free grammars are interesting principally because they have a fairly simple class of parsers, whereas context sensitive grammars have more complex parsers (and can easily lapse into being turing complete at the parse stage, which is part of why C++ is so damn slow to compile). But formally you can have a context free grammar for C++ provided you just identify a and * as tokens (let's call them USER_DEFINED_WORD and STAR) and don't handle the ambiguity in semantic interpretation at that point. Bang! Context free grammar achieved.

This discussion is… well, not really going anywhere.

[Applied Mediocrity]

@dkf said in Gąska is a tart savour and wants to give floating jobs to Javascript:

This discussion is… well, not really going anywhere.

Welcome to WTDWTF!

[Gąska]

@dkf said in Gąska is a tart savour and wants to give floating jobs to Javascript:

@Gąska said in Gąska is a tart savour and wants to give floating jobs to Javascript:

Being context-free is an important detail that opens a whole world of ready-made transformation algorithms to use

You're overselling it. Context free grammars are interesting principally because they have a fairly simple class of parsers, whereas context sensitive grammars have more complex parsers (and can easily lapse into being turing complete at the parse stage, which is part of why C++ is so damn slow to compile). But formally you can have a context free grammar for C++ provided you just identify a and * as tokens (let's call them USER_DEFINED_WORD and STAR) and don't handle the ambiguity in semantic interpretation at that point. Bang! Context free grammar achieved.

But such parser is rather useless for its main purpose - building AST.

Inb4: yes, you can make some AST out of that, but that AST will be just as useless.

This discussion is… well, not really going anywhere.

Agreed. When one person completely ignores what the other says, that's usually the result. I'm just confused why it's so hard to understand that easier tool development benefits everyone.

[dkf]

@Gąska said in Gąska is a tart savour and wants to give floating jobs to Javascript:

but that AST will be just as useless

In a great many languages, you can't resolve all ambiguities without reference to context. The problem is mainly one of deciding what the class of meaning of a name is; is it a namespace, a class, a function, a type, a variable, etc.? (Once you've decided that, the rest of the grammar should definitely be unambiguous for any language where the CFG is a major point.)

[cvi]

@HardwareGeek said in Gąska is a tart savour and wants to give floating jobs to Javascript:

Brain-Flack (a derivative of brainfuck) has a context-free grammar. Just sayin'.

And I'm sure it had excellent tooling as well, thanks to the superior simplicity of tool development for it.

[Gąska]

@dkf said in Gąska is a tart savour and wants to give floating jobs to Javascript:

@Gąska said in Gąska is a tart savour and wants to give floating jobs to Javascript:

but that AST will be just as useless

In a great many languages, you can't resolve all ambiguities without reference to context.

Of course you can't. But it would be nice to resolve most ambiguities with only partial context. Otherwise you can't do anything interesting without full compilation (sans codegen). And that's especially a problem for IDEs, because you want your IDE to work well enough with half-broken input files (because you're just writing them).

When designing Rust, they've taken extra care to make sure the grammar is unambiguous. There's no syntactic element where both an expression and a type are valid next tokens - it's always one or the other. There are a few quirks due to it such as the turbofish (::<_>), but as a result, a lot of tools appeared very quickly after 1.0 release - IDE plugins, language servers, linters, formatters etc. And despite the hardcore and highly unusual feature set Rust has, these tools work reasonably well.

[Gąska]

@cvi said in Gąska is a tart savour and wants to give floating jobs to Javascript:

@HardwareGeek said in Gąska is a tart savour and wants to give floating jobs to Javascript:

Brain-Flack (a derivative of brainfuck) has a context-free grammar. Just sayin'.

And I'm sure it had excellent tooling as well, thanks to the superior simplicity of tool development for it.

The best it can be.

[Zerosquare]

@dkf said in Gąska is a tart savour and wants to give floating jobs to Javascript:

This discussion is… well, not really going anywhere.

Would you say it's... contexnt-free?

[pie_flavor]

It's nice being an in-joke.

[Tsaukpaetra]

@pie_flavor said in Gąska is a tart savour and wants to give floating jobs to Javascript:

It's nice being an in-joke.

Haven't read the thread, but now I'm pondering what my own in-joke would be....

[topspin]

@Tsaukpaetra said in Gąska is a tart savour and wants to give floating jobs to Javascript:

@pie_flavor said in Gąska is a tart savour and wants to give floating jobs to Javascript:

It's nice being an in-joke.

Haven't read the thread, but now I'm pondering what my own in-joke would be....

There are a few, actually.

And the anti- is so concerned about the purity of this awesome thread, he had to act immediately.

[admiral_p]

@cvi said in Gąska is a tart savour and wants to give floating jobs to Javascript:

@Mason_Wheeler said in Gąska is a tart savour and wants to give floating jobs to Javascript:

it has a proper context-free grammar and is thus objectively easier for both humans and machines to understand

Meh. Does anybody actually care, though?

As an end-user, I don't really give a fuck about how easy it was to write a parser (not to mention that context sensitive grammars are well supported in various parser generators; my personal favourite being PEGTL).

C++ famously has the most vexing parse. Unlike the ambiguity with * that's been used as an example, the "most vexing parse" actually occasionally causes a bit of confusion (admittedly, the ambiguity is due to different reasons). But even that is so infrequent that I basically had forgotten about it until this point in the discussion. (And I also don't really see students encountering it a bunch. If they do, it's easy enough to resolve for them that it's basically a non-issue).

tl;dr: IMO whether a language uses a context-free or context sensitive grammar doesn't matter at all when compared to other design decisions.

As a layman I wish to interject on this matter. The fact that so many "big" languages are so inscrutable for humans too is a significant turn-off from programming (for me and many other people). By focusing on the people that have chosen programming, it's basically like preaching to the choir. Of course people who have chosen IT will be more tolerant of its idiosyncrasies.

[Gąska]

@admiral_p said in Gąska is a tart savour and wants to give floating jobs to Javascript:

As a layman I wish to interject on this matter. The fact that so many "big" languages are so inscrutable for humans too is a significant turn-off from programming (for me and many other people).

Note, however, that this is different from whether they're context-free or not. Most of the "big" languages have almost unambiguous grammar, except for a few shift/reduce conflicts here and there (e.g. if... then if... then... else... - which if does the else belong to?) that are easily solved without any complex analysis.

[dkf]

@Gąska And most of the time when something's in an ambiguous case, the best thing for the programmer to do is to adjust their code so it is no longer ambiguous. In this case, updating your coding standard to require {…} with if fixes things. The only downside to this is that it doesn't let some people write excessively short code; I can live with that until such time as there's an actual shortage of newline characters.

[brie]

@Applied-Mediocrity said in Gąska is a tart savour and wants to give floating jobs to Javascript:

It's possible it actually feeds on all the negative energy we emit by mocking it.

I write Javascript and can 100% confirm that this is true.

[brie]

@error said in Gąska is a tart savour and wants to give floating jobs to Javascript:

Monkey patching is a feature of the language, but it's mostly used for evil and/or compatibility patches that break more than they fix. Basically, (until recent-ish things like Object.freeze) you can modify nearly any object; and since objects inherit from other objects (not classical), and methods are just properties that happen to be functions, you can swap in your own implementation for anything.

That may sound like a terrible idea, but wait, it gets worse! You can store a reference to the original method and apply the decorator pattern to transparently modify the input and output of an existing method.

Now, no one does this because it's obviously a bad id--- HAHAHA I mean everybody does it, and it's not uncommon for methods to be decorated

I'm not ashamed to say that I love just how evil this feature allows me to be.

multiple competing frameworks and polyfill libraries on the same fucking page.

Well, there's your problem. If you'd stick to Vanilla JS you wouldn't have that.

[error]

@brie said in Gąska is a tart savour and wants to give floating jobs to Javascript:

Well, there's your problem. If you'd stick to Vanilla JS you wouldn't have that.

Polyfills are still required for VanillaJS if you need to support IE.

[Mason_Wheeler]

/me sets a stopwatch. How long until he's back?

[Gąska]

@Mason_Wheeler tomorrow. It's currently late at night on this side of the planet.

[Flips]

@levicki said in Gąska is a tart savour and wants to give floating jobs to Javascript:

[...] I am not amused. [...]

I can read that in every post you make.

[error]

@levicki said in Gąska is a tart savour and wants to give floating jobs to Javascript:

I definitely do not belong here.
Bye.

Cupcake thread of celebrations is

[error]

:@levicki: You guys are so butthurt, I'm leaving forever!

---

Filed under: Not my real dad.

[JBert]

@error said in Gąska is a tart savour and wants to give floating jobs to Javascript:

@levicki said in Gąska is a tart savour and wants to give floating jobs to Javascript:

I definitely do not belong here.
Bye.

Cupcake thread of celebrations is

I guess you can "celebrate" if you really want, but I don't have to like it.

[error]

@JBert said in Gąska is a tart savour and wants to give floating jobs to Javascript:

@error said in Gąska is a tart savour and wants to give floating jobs to Javascript:

@levicki said in Gąska is a tart savour and wants to give floating jobs to Javascript:

I definitely do not belong here.
Bye.

Cupcake thread of celebrations is

I guess you can "celebrate" if you really want, but I don't have to like it.

That's kind of my thing.

[strangeways]

Fuck me, he's really gone. Shame his posts are too, they would've been a great study on how trying to act "holier than thou" in the TDWTF forums leads to account suicide.

[lolwhat]

@strangeways said in Gąska is a tart savour and wants to give floating jobs to Javascript:

Fuck me, he's really gone. Shame his posts are too, they would've been a great study on how trying to act "holier than thou" in the TDWTF forums leads to account suicide.

Holy shit. Was he 's Polish cousin?

[Gąska]

@strangeways WTF. The madman did it!

See @blakeyrat? That's how you ragequit! Not by lamenting over your hurt feelings, but still lurking all the time and even commenting on the posts on Discord and asking others to relay your messages.

[Carnage]

@strangeways said in Gąska is a tart savour and wants to give floating jobs to Javascript:

Fuck me, he's really gone. Shame his posts are too, they would've been a great study on how trying to act "holier than thou" in the TDWTF forums leads to account suicide.

Wow, he really nuked out.

[cvi]

@Gąska said in Gąska is a tart savour and wants to give floating jobs to Javascript:

WTF. The madman did it!

For some reason that reminded me of the scene/setup from The Island:
https://youtu.be/_ZyNJ3cKfEg?t=10s

Boomzilla probably needed another replacment body. Nothing to see here.

[Applied Mediocrity]

@lolwhat said in Gąska is a tart savour and wants to give floating jobs to Javascript:

Holy shit. Was he 's Polish cousin?

He was... er, Srbskish?

@Gąska said in Gąska is a tart savour and wants to give floating jobs to Javascript:

That's how you ragequit!

Looks spectacular, but a rather shit thing to do, really. Topics with those missing posts don't make a lot of sense now. Well, where they did to begin with, of course.

And can't into GDPR.

[hungrier]

@Applied-Mediocrity It also messes up tracking the last post you read. Looks like once again the @Tsaukpaetra method has the advantage

[dcon]

@Carnage said in Gąska is a tart savour and wants to give floating jobs to Javascript:

@strangeways said in Gąska is a tart savour and wants to give floating jobs to Javascript:

Fuck me, he's really gone. Shame his posts are too, they would've been a great study on how trying to act "holier than thou" in the TDWTF forums leads to account suicide.

Wow, he really nuked out.

That explains why my last-post read positioning is all fucked up this morning...

[loopback0]

@Applied-Mediocrity said in Gąska is a tart savour and wants to give floating jobs to Javascript:

Topics with those missing posts don't make a lot of sense now. Well, where they did to begin with, of course.

Plus topics he started are completely gone including other people's posts.

[Zerosquare]

I find that disturbing. Destroying your own content is one thing, but destroying someone else's is another thing.

[Benjamin Hall]

@Zerosquare agreed.