Live data from Hacker News

A project with a single 11,000-line code file

austinhenley.com

311–320 of 346 posts

Re: A project with a single 11,000-line code file

#311

Back in the days at Zynga, there was this ritual that new members of the STG (Shared Tech Group, which developed the game engine stack) had to try to refactor the road logic code. Suffice it to say, it's a 28k LOC file that was so bad, it could even hold up in court as evidence that a South American company stole the code of Zynga's -ville games. We could reproduce each and every single bug and its effects 1:1 in the…

It's impossible to refactor spaghetti code without a comprehensive test suite. But you can do it with a test suite - I've done it with large code bases.

Which means it's often difficult. The traits "Has a comprehensive test suite" and "is spaghetti code" are often rarely seen together. A poor code base has become poor because it's not refactored and cleaned up all the time - and that's often because their is no tests to help with that.

And if there is no test suite, there is often very few ways to add a test suite. Poor code has very few points where you can attach a test. If the code contains file databases or structured input of some sort (a web page) you can add some very high level end to end tests. But not all code has easily verifiable endpoints like that. Perhaps my bad experiences comes from "hard to test" domains (Sound, drawing, ...) code, and not "given this input this is written to the database and this is written to screen".

Re: A project with a single 11,000-line code file

#312

Earlier quoted context omitted.

pg's new lisp, Bel, has something close to typed arguments: (def add1 (x|int) (+ x 1)) http://www.paulgraham.com/bel.html I've been implementing it for a couple years now, though not seriously till the past couple months. There are some interesting (and overlooked) ideas in Bel. Bel is sort of the limit case of generality. For example, you might expect the "type" above to be a separate kind of object, the way that ty…

That doesn't really allow for type checking which is a major purpose of types. It's more of just some nice sugar for runtime assertions

Well, you can interpret the predicate function body as a set of constraints on the type. Of course, such predicate function would need to be restricted to what your type system can handle. Typed Racket does this, by allowing you to implement type refinements[1]. As long as the predicate only uses operations listed there, it can be used for type checking. Idris also lets you write functions that operate on types and that are used for type checking.

[1] https://docs.racket-lang.org/ts-reference/Experimental_Featu...

Re: A project with a single 11,000-line code file

#313

I remember many years ago coming across a reimplementation of the server side for a popular MMORPG of the time, reverse-engineered from the client (which was Flash) by what was likely a teenager --- it was over 100k lines in a single file, written in Visual Basic. Global variables everywhere, short names, and not even indentation. All the account data was stored in flat files, there was no actual DB. No "best practic…

It always seemed surprising to me how some of the big Oblivion and Skyrim mods would get by with fairly few bugs despite there being no way to have automated tests and some of them having 10k lines of scripting (or much more in some cases) spread around dozens or hundreds of quests (quests in the CE engine are not just the quests you as a player see, but also a huge number of invisible quests because quest state mach…

For a single modder, it may have to do with being a single developer, working on it over a long period of time and being a passion project.

For a while, I was the only developer working in a small module of a bigger project: I started the code base, discussed requirements with clients, implemented the needed features, tested the whole product end to end. I developed a very good instinct about it and about what any change would do, much better than any other project. My theory is that the code base matched my way of thinking, so thinking about it was pretty easy.

Re: A project with a single 11,000-line code file

#314
post #50
post #47

Earlier quoted context omitted.

You sound like you should read this: [removed] apparently jwz decided not to be linked from here :/ there's an archive.org link below.

Heads up: jwz.org redirects Hacker News visitors (via "Referer") to an image of a slightly-hairy testicle sitting inside an egg cup. So maybe don't click the link at work.

Ok, So I wanted to see it. Quick hack of the link tag in sibling comment, and this is what you see:

NOT SFW! https://cdn.jwz.org/images/2016/hn.png

It's funny. Why does he hate us so?

Re: A project with a single 11,000-line code file

#316
post #272

Earlier quoted context omitted.

Emacs is actually quite poor at opening large files, at least comparatively—depending on the machine, 65K lines may be enough. However, there's an addon, i.e. a ‘mode’, that implements editing of large files somehow. Vim, on the other hand, does it splendidly: it keeps only a chunk of the text in memory, and iirc the ‘swap file’ that it creates for every opened file, keeps the changes in some kind of a sparse structu…

> Emacs is actually quite poor at opening large files, at least comparatively—depending on the machine, 65K lines may be enough. However, there's an addon, i.e. a ‘mode’, that implements editing of large files somehow. Yeah, essentially this (apparently) mostly occurs when the file has no newlines (like json often does). I think the hacks are around turning off font-lock mode and one or two other things (install long…

Again alas, long lines is not the only large-file problem in Emacs. Though perhaps most of my woes pertain to Org-mode, but I had to look for a solution to edit large files in the past.

This is probably the most current implementation of a ‘view large files’ package: https://github.com/m00natic/vlfi

Re: A project with a single 11,000-line code file

#318

I remember many years ago coming across a reimplementation of the server side for a popular MMORPG of the time, reverse-engineered from the client (which was Flash) by what was likely a teenager --- it was over 100k lines in a single file, written in Visual Basic. Global variables everywhere, short names, and not even indentation. All the account data was stored in flat files, there was no actual DB. No "best practic…

See also Bellard's QuickJS (54k lines) https://raw.githubusercontent.com/bellard/quickjs/master/qui...

Came to say this. I actually find QuickJS pretty easy to understand and modify, in part because everything is one file and it's easy to search, using vim's `#` and `*` keys, for example.

When working on projects by myself, I like putting everything in one big file too. Trying to find the "right" place for something is some unnecessary overhead, not to mention the navigation cost. It's a different story when a team is involved though.

Re: A project with a single 11,000-line code file

#319

Earlier quoted context omitted.

Funnily enough, I have recently had great success by reversing the "best practices" on a distributed "micro services" architecture application into a single big Java file. Best practices were the usual suspects DRY, IOC, SQL + NoSQL, separation of concerns, config files over code, composition over inheritance, unexplainable overlapping annotations, dozens of oversimplified components doing their own thing, and some $…

This application must be really really simple ;), so no database?

No and no.

Re: A project with a single 11,000-line code file

#320
post #98

Earlier quoted context omitted.

I've sadly come to realize (after witnessing on many projects) that there's a pattern that goes like this: * Team A writes code quickly. Not bad code, really, but they take shortcuts everywhere they can. They don't have the strongest tests, they don't generalize for all the known use cases, etc. Their code goes to beta and gets users and makes progress. * Team B deliberates and deliberates. They try to avoid taking s…

I don’t think this dichotomy is helpful. I’m presently working at a startup that’s trying to dig itself out of a hole created by the first CTO, who in doing things “quickly” created an MVP so buggy, inefficient, crash-prone, and unmaintainable that we can’t retain customers or engineers. As always, there’s a balance to be struck, and ways to operate quickly that don’t sacrifice quality too much.

I think something that is lost in this conversation is that "quickly" maps to wildly different results in code quality depending on the programmer.

It sounds like your CTO did not just operate quickly, but also sloppy and chaotic. From what I am gathering from this thread, the best practice is to move quickly AND organized such that refactoring is reasonable.

Post reply on HN