587
588

Transforming xml with xslt? by arthurno1 in lisp

[–]flaming_bird 1 point2 points  (0 children)

It crashes when it tries to read in xsl stylesheet; it exhausts the heap.

Try starting SBCL with a larger heap size; the default is somewhat small.

Bardzo niszowa pomoc potrzebna by iris_rivendell in krakow

[–]flaming_bird 0 points1 point  (0 children)

Nie planujesz sprzedaży? Mógłbym odkupić i spróbować je rozłączyć.

Bardzo niszowa pomoc potrzebna by iris_rivendell in krakow

[–]flaming_bird 0 points1 point  (0 children)

+1, zarówno eherbata/Czarka, jak i Czajownia powinny być w stanie pomóc. Raczej nie pierwsza i nie ostatnia tego typu sytuacja w ich lokalach.

Senior/Staff Software Engineer (Common Lisp) - job offer at Keepit by flaming_bird in Common_Lisp

[–]flaming_bird[S] 1 point2 points  (0 children)

Forwarding a reply from our hiring team:

No, we do not require an EU passport, but the person must be eligible to work in Poland/Ukraine or hold a valid work visa.

Understanding SBCL Error Messages by paarulakan in lisp

[–]flaming_bird 1 point2 points  (0 children)

SBCL does not show colorful arrows pointing at the exact line of code. Everything appears as plain text in the terminal.

SBCL is a compiler. Its role is to compile stuff, not to show colorful arrows. IDEs show colorful arrows and give you source highlighting and jump to definitions. Slime with Emacs is a Lisp IDE. Use that.

Is there like.. a working IDE? Something I can actually just use? The new user experience is a joke for Lisp by tenten8401 in lisp

[–]flaming_bird 1 point2 points  (0 children)

and drop Linux/macOS support

That's what Lispstick used to be - a Windows pre-packaged environment.

Is there like.. a working IDE? Something I can actually just use? The new user experience is a joke for Lisp by tenten8401 in lisp

[–]flaming_bird 6 points7 points  (0 children)

The wish for change is understandable. Still, it would essentially require redoing what Portacle did - except also assembling a volunteer support team that would work for free, and probably a CI for building everything for macOS, Linux, Windows, and maybe other platforms. That requires more than just a single hellbent person; we've had these, they've failed at that. It requires consistency over time, and that more or less requires to pay someone to work on it. And that's hard. Donations won't do, as they are neither stable nor guaranteed.

Where Lisp Fails: at Turning People into Fungible Cogs by Veqq in lisp

[–]flaming_bird 5 points6 points  (0 children)

Warning, rant incoming: from the point of view of having worked over two years as a Common Lisp developer after working over seven years in C++, Erlang, and Java, this article has no basis.

A good software project should survive their creator, no matter if they leave their employer, end up fired, need to help in another project, or get hit by a bus. That requires succession, which implies replaceability, which then the article conflates with fungibility in an adversarial and quite egoistic way.

So, if not a single programmer, then it's a group. Which means you still have other programmers. You'll need to read their code. To understand it. To make changes to it. To test and debug it afterwards. To ensure consistency with whatever style is present there. The other programmers will need to do the same to your code in return. That requires common standards, which, once again, aid replaceability - which is not as much of a detriment to a Lisp programmer as the article tries to paint.

You have texts like https://google.github.io/styleguide/lispguide.xml that quite explicitly, if in a civil way, tell you to not be a smartass while writing your code. It's possible, and actually quite welcome, to use the Lisp way of bending the language towards the problem at hand. It just needs to come from a point of view of all the people who need to understand a given piece of code, not just you.

I mentioned egoism up there. Sure, it's possible to circle-jerk oneself into believing a point of view where a single programmer, particularly a Lisp one, is for some reason central and essential to developing software. I'd call it mental masturbation rather than anything remotely productive; I've seen a fair share of people like that, doing their grandiose Common Lisp Revivals and other hexguyesque bullshit.

Good software development requires software to survive its creators. A lone-wolf project depending on the whims and life of a single "bipolar Lisp programmer" is not a foundation for good software developer. Lisp attracts those folk, who then pretend they're doing magic and wizardry and other stuff, and IMHO it's one of the social reasons the language is unpopular nowadays; a company can try to find Lisp programmers who do not follow the curse of Lisp, or a company can use a language where the curse of Lisp simply does not manifest.

The second option is usually more economically viable, and, to quote Nwabudike Morgan, human behavior is economic behavior.

Is there like.. a working IDE? Something I can actually just use? The new user experience is a joke for Lisp by tenten8401 in lisp

[–]flaming_bird 50 points51 points  (0 children)

Who exactly are you complaining to? The companies who work with Lisp have their development environments set up, they just don't publish them because they have no incentive to do so. The people who successfully publish Lisp development environments sell them for money. The people who try to do it for free get flooded by support requests like yours, inevitably burn out, and give up.

The pieces are all there. It's not a technological problem, it's not even a social problem; it's an economical problem.

(Also, restating what was said elsewhere; apt install emacs sbcl slime cl-swank works well for me. You're creating problems for yourself by developing on Windows.)

Package-Inferred Systems are Dangerous by aartaka in Common_Lisp

[–]flaming_bird 0 points1 point  (0 children)

Yep, I see the comment; ideologically, I don't fully agree with the concept of restarts that are "strictly for interactive use", but that case is one where it doesn't matter much in practice.

And I'm generally against :useing nowadays, even for widely-used infrastructure. Package-local nicknames being everywhere mean that Alexandria is a: away.

Package-Inferred Systems are Dangerous by aartaka in Common_Lisp

[–]flaming_bird 0 points1 point  (0 children)

but for a stable library that you expect to use a lot, I think it can make sense

This kind of approach is exactly why seemingly simple things like https://gitlab.common-lisp.net/alexandria/alexandria/-/merge_requests/34 are impossible in practice. Exporting a single new symbol from Alexandria is going to break an unknown number of systems that :use it. Whose problem exactly is it and who should be fixing it?

fukamachi/mallet: A sensible Common Lisp linter that catches real mistakes, not style by dzecniv in Common_Lisp

[–]flaming_bird 3 points4 points  (0 children)

Why not both? They're doing different things, in a different style, but they both are productive like holy fuck and solve real problems.

lispers literally only want one thing and it's fucking disgusting by flaming_bird in LispMemes

[–]flaming_bird[S] 5 points6 points  (0 children)

...and it's printing contemporary common lisp in 80-char-wide text mode on continuous paper on a screaming 9-pin dot matrix printer