[HN Gopher] Porting 58k lines of D and C++ to Jai
___________________________________________________________________
Porting 58k lines of D and C++ to Jai
Author : Growtika
Score : 143 points
Date : 2022-11-23 15:26 UTC (7 hours ago)
(HTM) web link (www.yet-another-blog.com)
(TXT) w3m dump (www.yet-another-blog.com)
| rizky05 wrote:
| haolez wrote:
| > All information for building a program is contained within the
| source code of the program. Thus there is no need for a make
| command or project files to build a Jai program.
|
| Ok, now I'm curious. Will have to check it out.
| dmitriid wrote:
| Can't wait to see how this progresses. So far the only source of
| knowledge have been Blow's streams, but he's the author, and he
| knows his language inside and out. It will be immensely
| interesting to see other people's experiences.
| throwaway17_17 wrote:
| Tsoding, coding on Twitch and with archives on YouTube has a
| few streams from after he got into the beta. They give a decent
| overview of using the language in its current state, and I find
| Tsoding petty entertaining as well.
| dmitriid wrote:
| Thanks! I'll check them out!
| cleandreams wrote:
| I wrote an extremely hard and complex program in which I had to
| use c++ metaprogramming throughout. Not my decision. I do not
| understand why you could possibly need more metaprogramming than
| C++ provides. This is a problematic feature to begin with. Not
| worthless but not worth much. The debugging was difficult. Many
| problems show up buried in literally thousands of compiler error
| messages.
| P5fRxh5kUvp2th wrote:
| C++ started with templates as a type polymorphism mechanisms.
|
| Then it was shown to be turing complete so people started using
| it as such.
|
| The over time it started getting more and more things constexpr
| such that it's easier to execute during compile time (because
| it's turing complete).
|
| Jai just made the decision that everything is constexpr by
| default.
|
| And the answer to your question is that it's easier to do in
| Jai (in theory) than C++.
| shakow wrote:
| The problem with C++ metaprogramming is not what you can do
| with it, it's how you do it; which, IME, is always the most
| convoluted, unsafe way possible.
|
| The "siamese brothers"-ization of templating & metaprogramming
| is especially painful.
| gallier2 wrote:
| That's the issue with C++ metaprogramming. It's so unwieldy and
| complex that the benefits are difficult to see and the
| occasions to be worthwhile limited. When the language has
| better (i.e. simpler) facilities for meta-programming like D,
| it will open big venues where it makes sense to use it. It is
| like programming object oriented in C, it is possible to do but
| so unwieldy and requiring discipline and verbose boiler plate
| that there's rarely an occasion where it would be interesting
| to use. While it is much easier to do in C++ or D or Java
| (etc.) as they provide the abstractions that makes it useable.
| C++'s meta-programming facilities are not good enough.
| bjourne wrote:
| I disagree. Object-oriented programming is very easy in C
| even though the syntax itself doesn't guide you. Essentially,
| all C code I write is object-oriented. Perhaps you are
| thinking about dynamic dispatch which indeed is very annoying
| to implement correctly in C?
| StreamBright wrote:
| I am surprised by the design of jai. The author has very
| interesting view on typical programming problems (RAII,
| exceptions).
| zengid wrote:
| > _In my eyes, the most important ones are faster compilation and
| allowing metaprogramming via unrestricted compile time
| execution._
|
| I'm fascinated by languages that are adding more compile-time
| programming features, in the context of a low-level performance-
| oriented use case. Would love to know more about the history and
| state of the art of this area.
| Kukumber wrote:
| > ldc2 is awfully slow to compile5
|
| LDC = LLVM backend
|
| it's slow for D, for C++, for Zig and also slow for Jai
|
| The reference compiler "DMD" is what you use to get fast
| iteration time
|
| > (jai) Reducing compile times from about 60s right now to under
| 5s, hopefully around 1s
|
| Try to compile the DMD compiler and notice how fast it is at
| compilation
|
| So that sounds like it's a "your code" problem, my game engine
| takes 1.2 seconds to fully recompile with DMD
|
| > the documentation is lacking
|
| https://dlang.org/phobos/index.html
|
| Looks complete with exhaustive code examples that you can run
| online
|
| > Ok, so I don't like D and C++ and jai looks good. But what
| about all the other languages?
|
| Ok so that explains everything
| smegsicle wrote:
| > Porting 58k lines of D to C++ in Jail
|
| and they call sprinkling a bit of water "cruel and unusual"
| ibiza wrote:
| > a big chunk of these vulnerabilities would not exist if C and
| C++ [...] simply didn't have zero-terminated string, initialized
| values by default, had a proper pointer+length type thus
| replacing 90% of pointer arithmetic with easily bounds-checkable
| code, and had established a culture that discouraged the
| prevalent ad-hoc style of memory management.
|
| This is Rust's calling-card, so I find this plea for a better
| lang / eco rather jarring after dismissing Rust for somehow
| "making the wrong tradeoffs".
| vvanders wrote:
| Yeah, I think Bevy[1] is also a great example of something that
| fits in well with a lot of Rust's strengths while also showing
| that it's possible to lean in heavily to very gamedev centric
| approaches with how it approached ECS.
|
| I think there's is some truth around try to avoid unsafe, that
| said the times I've dropped down into it I've found myself
| chasing heap corruption or use-after-free on more than one
| occasion :).
|
| Some of Jai's AoS/SoA transforms look neat and certainly
| interested to see what it looks like once it starts opening up
| more.
|
| [1] https://bevyengine.org/
| wk_end wrote:
| If I'm reading OP right, their issue with Rust is the borrow
| checker - none of those features require one. They're asking
| for a language that's safer than C, not as safe as Rust, but
| simpler and easier to ram things through. I don't necessarily
| agree, but I think that's what they're saying.
| aeturnum wrote:
| I'm really interested to see Jai in the wild, but I have to say I
| find the Jai v.s. Rust comparison here...unconvincing to say to
| least. It's particularly funny to be excited about "being able to
| do _anything_ during compilation " using Jai and then complain to
| that the #1 problem in programming is "culturally tolerated and
| even encouraged complexity."
| mjburgess wrote:
| Complexity often arises from restrictions on "anything", rather
| than people actually doing anything.
| aeturnum wrote:
| I'm curious - what you think of as a good example? I think of
| C++ templates & macros, which I would not describe as arising
| from restrictions?
| ablob wrote:
| Template metaprogramming in the absence of
| constexpr/concepts would be my guess.
| owenpalmer wrote:
| Excellent point!
| stephc_int13 wrote:
| I'd love to see more about Jai.
|
| I don't understand why they are not working in the open, this is
| a tool, not a game, input for a large community is extremely
| valuable.
|
| But as brilliant as Jon Blow is, he is at least equally as
| stubborn.
|
| Fast compilation and nice, easy to read syntax with good default
| is exactly what I am looking for.
|
| I can understand the hype about metaprogramming, and its
| potential usefulness, but I also think this is a pandora box.
|
| Pretty much like C macros and C++ templates, overuse can lead to
| a very messy codebase, hard to read, hard to debug, with a lot of
| unexpected side effects.
| hbn wrote:
| I don't see why a language can't be one guy's passion project.
| Even if he releases it and it turns out he's the only person
| that likes it, so what? It's not like he's had millions in VC
| or government investment dumped into it or something. He's got
| some ideas and he's implementing them. I'm interested to see
| how it turns out.
|
| Golang has had success and was primarily made in private by 3
| guys and hasn't strayed too far from the original founding
| principles they came up with.
| stephc_int13 wrote:
| Yeah, of course he can do whatever he wants.
|
| The think is that quite a few people have been convinced by
| his talks and want to use Jai for real projects.
| googlryas wrote:
| If there's enough actual interest, some group of people
| will just clone the language in an open manner since enough
| is known about it. But that doesn't seem to be happening at
| the moment.
| cyber_kinetist wrote:
| I thought Odin was one of the clone languages at the
| start (although later it diverged from Jai in many
| aspects, and is far ahead Jai in the aspect that it's
| open-source and is actually being used in production).
|
| But really I would like Jai to take some time to mature
| over the years, instead of rushing out for an immediate
| public release. It has some very ambitious ideas that
| would absolutely be killer features, but I think it needs
| ample time to get polished. (Off to writing C++ code
| during the time then...)
| suby wrote:
| Odin has similar syntax, but one of the main reasons I am
| interested in Jai is because it has strong meta-
| programming support[0], where as Odin doesn't and will
| likely never due to the author of the language not
| wanting to go in that direction.
|
| [0] - https://github.com/Jai-Community/Jai-Community-
| Library/wiki/...
| stephc_int13 wrote:
| What do you think about Zig?
|
| I am not a fan of metaprogramming, but this is a
| relatively important feature of Zig.
| ok123456 wrote:
| Unless it's being designed from committee from the start,
| most languages start off as a 'passion project.' But, there
| is a point where they have to bring in more people to handle
| the work and mitigate the single point of failure.
| 3a2d29 wrote:
| It's hard to find any material on Jai.
|
| It seems to be a "better C".
|
| Isn't that what D / Zig try to do? What's the advantage?
| kjksf wrote:
| There's quite a lot of information, just not very accessible.
|
| https://www.twitch.tv/j_blow/videos?filter=archives&sort=tim.
| .. : this is jai's author livestreaming language development,
| most up-to-date
|
| https://www.youtube.com/playlist?list=PLmV5I2fxaiCKfxMBrNsU1.
| .. : a cureated subset of twitch videos, possibly outdated
| info
|
| https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md
| : a summary of jai based on the above curated videos,
| possibly outdated
| [deleted]
| stephc_int13 wrote:
| I think that Jai / Zig / Odin all started around the same
| time.
|
| D is closer to C++ than C, in my opinion.
|
| I suspect that Jai was an inspiration for Zig and Odin.
|
| Many developers in gamedev circles are still using C or
| orthodox C++ (C++ without most of the bullshit) but are
| frustrated by many features and gaps.
|
| Short compilation time is one of the big goals, as it is
| crucial for fast iteration.
|
| The goal is simply to have a powerful low-level/system
| language that is enjoyable to use. Or at least more enjoyable
| than C++. (the de-facto standard)
| bachmeier wrote:
| > D is closer to C++ than C, in my opinion.
|
| In terms of what the language allows you to do, yes.
| However, if you're a C programmer, you can pretty much just
| keep writing the same code you've always written (minus the
| preprocessor, thankfully). You can even compile C code with
| the D compiler and call those functions from your D code
| without doing anything further. That's definitely not the
| case with C++.
| moonchild wrote:
| Oh, come on now. I'm no C++ apologist, but you can do
| both of those things in C++ as well as in D.
| 3a2d29 wrote:
| Right that makes sense.
|
| I'm curious if the gaming industry will switch languages,
| it feels like with the current game engines that it's
| heavily entrenched in C and C++. Feels like something like
| Carbon has the best chance to break in.
| stephc_int13 wrote:
| Only time will tell.
|
| But I think there is an opportunity at this point in
| time.
| oxryly1 wrote:
| A chunk has already switched to C# with Unity. Most other
| engines (proprietary, Unreal, etc) have decades of C++
| that would require too much effort to migrate to anything
| new.
| cmovq wrote:
| Unity is still written in C++. It's fairly common to
| write the core engine in C++ and use a language like Lua,
| or as is more common in AAA, some proprietary scripting
| language for gameplay code.
| hsn915 wrote:
| If you can find very old Jai videos on YouTube, you can
| find the creator of Odin was one of the early people
| excited about the project.
|
| I suppose if the development of Jai was made more in the
| open/public, Odin would probably not have existed.
|
| That said, I'm glad Odin exists.
| BaculumMeumEst wrote:
| You can find the creator of Zig in those videos as well
| henry_viii wrote:
| I'm surprised the author didn't mention the Lobster programming
| language when evaluating a successor language:
|
| https://github.com/aardappel/lobster
|
| The language seems to be exactly what he was looking for - a
| high-performance high-level language specifically designed for
| video games.
| cyber_kinetist wrote:
| From a glance at the language description, this is very
| different from what he is looking from Jai. I don't see any
| description of it having metaprogramming facilities as good
| as D or Jai (or even C++!).
| [deleted]
| bsder wrote:
| > I don't understand why they are not working in the open, this
| is a tool, not a game, input for a large community is extremely
| valuable.
|
| Ayup. Talking about JAI is simply a waste of time until they
| put it in the open under a genuine open-source license.
|
| Otherwise, you wind up with situations like "Our Machinery".
| seabass wrote:
| > input for a large community is extremely valuable
|
| In the early stages, everyone has a thousand opinions and it's
| not clear even to those working in jai daily _what_ exactly the
| language wants to become and which patterns should be
| supported. From what I understand, Blow intends to gradually
| open things up as the project matures, which I think is 100%
| the right approach for something fairly experimental and with a
| lot of new ideas.
| dymk wrote:
| It's 8 years old
| mumblemumble wrote:
| For a volunteer developed programming language, that's
| almost certainly early stages.
|
| Calendar years is not a good measure of how much work has
| gone into a language. Think in terms of person-hours
| instead.
| _trackno5 wrote:
| > input for a large community is extremely valuable
|
| it's also an extreme time suck. Having everyone opine on their
| pet feature would just take away from the focused work the
| people at Thekla are doing.
|
| Honestly, I don't even see why Jon should make things open
| source (apart from it being a major incentive for people to
| adopt it). The performance improvements they are offering
| compared to other languages 100% warrant charging for it.
| uvtc wrote:
| > I don't understand why they are not working in the open,
|
| > Fast compilation and nice, easy to read syntax with good
| default is exactly what I am looking for.
|
| > [re metaprogramming] ... but I also think this is a pandora
| box.
|
| Sounds like you might also like [Hare](https://harelang.org/).
| (has some work-in-progress [SDL2
| bindings](https://git.sr.ht/~sircmpwn/hare-sdl2))
| chromatin wrote:
| I find the "slow compile time" complaint of D interesting;
| overall I find ldc2 to be one of the faster compilers out there.
| I suppose the combination of features and metaprogramming used by
| the author is responsible for the 3-minute compile times in debug
| mode. While jai is evidently expected to be substantially faster
| (author estimates 5 sec for this codebase???), other choices like
| Rust would be far, far slower than D.
| dmitriid wrote:
| > author estimates 5 sec for this codebase???
|
| This expectation comes from jai compile times for the game
| Jonathan Blow is developing: https://www.twitch.tv/j_blow It
| takes about 2.5 seconds to compile and link over 168k lines of
| code in debug mode.
|
| See e.g. https://www.twitch.tv/videos/1659970118 at around 30
| seconds in
| Kukumber wrote:
| My game+engine wich is composed of 37k lines of D + 22k of C
| code (with D's ImportC), fully recompiles in 1.2 seconds with
| DMD
|
| https://bpa.st/raw/WCVQ
| p0nce wrote:
| To get best compile times with D it's important not go over
| board with CTFE and templates.
| pizza234 wrote:
| Putting together the available document "JayPrimer" (which may be
| obsolete) with the blog post, Jay it seems a language designed by
| somebody who's was fed up with C++, and deciced to write their
| own, tailored language; this looks great when seen through the
| lens of C++, but there isn't anything particularly innovative in
| the context of modern languages.
|
| In particular, I'm personally neutral to Zig, but there seems to
| be little reason to prefer Jay over it.
|
| From the primer:
|
| > Arbitrary Compile-Time Code Execution
|
| This is the big selling point, but, brought to the extreme, it's
| not necessarily a good thing. The examples in the primer are
| intended to look great:
|
| - Insert build time data
|
| - Download the OpenGL spec and build the most recent gl.h header
| file
|
| - Contact a build server and retrieve/send build data
|
| but they're the type of things that turn a build into a monster.
|
| I guess comptime execution is big in the gamedev area (I can't
| say, I have little experience), but I suppose Zig fits the
| typical gamedev use cases (curious to hear devs with hands-on
| experience).
|
| > Code Refactoring
|
| The example presented seems to be "extract to function", which
| sufficiently advanced IDEs should support. It's also unclear if
| it's currently implemented.
|
| > Integrated Build Process
|
| I don't see this as a good thing. It's good from the perspective
| of old programming languages, whose build tools are a mess. But
| having a separate tool is actually an advantage, as long as it's
| standardized and well integrated (I suppose modern languages have
| this support).
|
| > SOA AND AOS
|
| This seems to be a very niche feature.
|
| > Reflection and Run-Time Type Information
|
| This is very convenient, but again, nothing unique.
|
| > FUNCTION POLYMORPHISM
|
| It seems to be an odd (flexible/inferred) generics
| implementation. One of the language objectives is to never
| perform automated type casting, but in this example, it is
| performed.
|
| > THE ANY TYPE
|
| I guess this is a polarizing feature.
|
| > STRUCT POINTER OWNERSHIP
|
| Is this syntactic sugar for a C++ destructor?
|
| > Other Cool Stuff
|
| > Specific data types for 8, 16, and 32 bit integers
|
| No 64/128? :^)
|
| Regarding the post, the non-trivial selling points are described
| as:
|
| > Reducing compile times from about 60s right now to under 5s,
| hopefully around 1s
|
| This is certainly very appealing.
|
| > having debuggers work
|
| Uh? That's based on the bad D experience.
|
| > Replacing build-scripts with jai code
|
| > Catching more errors by introducing custom compilation checks
| using metaprogramming
|
| > Replacing complex metaprogramming code with simpler, imperative
| code
|
| See Zig.
|
| The rest are trivialities.
| andai wrote:
| "In the beginning I hinted at expecting the porting process to go
| somewhat smoothly (which I'm sure I won't regret later). The
| reason for this is that I have two systems in my game that will
| hopefully be immensely helpful in this endeavor:
|
| - The game records the inputs (HID, loaded files, network, ...)
| of a play-session into a file and replay them later. When
| replaying, feeding recorded input into the deterministic game
| loop leads to the exact same state, down to the bit.
|
| - The game hashes game state at various points during execution
| and saves these hashes to a different file. When replaying, the
| contents of this file can be used to check that the execution of
| the replayed session exactly matches the original execution."
| gavinray wrote:
| It's worth mentioning that DMD is a reference compiler and not
| meant as a production tool. DMD is for fast compile time during
| dev cycles and testing new language features early.
|
| You've got the LLVM and GCC compilers for production.
|
| The problem with lack of debug info on Windows in D is solved by
| using LDC with LLDB/GDB to debug
|
| You can also ask the compiler to emit CodeView debugging info if
| you want to stick with Microsoft stuff
| mattarm wrote:
| I don't think "DMD is a reference compiler and not meant as a
| production tool" is a great way to characterize it. There are
| certainly valid reasons for choosing LLVM and GCC for
| "production", but also valid reasons for choosing DMD.
| anta40 wrote:
| As far as I know, DMD doesn't offer much optimisations.
|
| So you use DMD for development, and once the testing is done,
| built the production release with LDC or GDC.
| svnpenn wrote:
| > LDC
|
| LDC for Windows is an awkward experience:
|
| https://github.com/ldc-developers/ldc/issues/4047
| rlp wrote:
| I'm not seeing a major problem here, you just need to install
| MSVC++ alongside it.
| svnpenn wrote:
| Its an extra requirement, thats not imposed by many other
| languages.
| Xorlev wrote:
| The author's chief complaint appears to be that dmd produces
| incorrect debug info on Windows, something I'd expect a
| reference compiler to do. A reference compiler doesn't have to
| be fast, but it does need to be correct.
| mhh__ wrote:
| Debug info is one of the backend things that does get
| priority with dmd. It has gotten some performance increases
| in recent years but these are mostly just a nicety.
|
| Personally I have fixed some debug info generation problems
| so it is being worked on.
| schemescape wrote:
| It wasn't clear to me: is the debug info wrong or is it just
| missing because stuff is getting optimized out? Both?
|
| I know in the past I had some difficulty in C++ on x64
| because variables were getting optimized out (so depending on
| where you were in the function the variable literally didn't
| exist anymore).
| cyber_kinetist wrote:
| He was complaining about the long compile times of LDC2 even in
| debug mode, and said that it uses too much memory up to the
| point that the laptop can't handle. So I understand why he was
| using DMD for development.
| hesdeadjim wrote:
| I'm in the private beta and things are changing constantly. I'm
| not sure why anyone would pick a language that won't ever have a
| real ecosystem of libraries. Coming from C++ and need to remain
| low-level? Pick Rust, done.
| protoster wrote:
| >I'm not sure why anyone would pick a language that won't ever
| have a real ecosystem of libraries
|
| Could you elaborate?
| throwaway17_17 wrote:
| With the almost total incompatibility in mindset and
| preferences between Jai and Rust, I'm not sure if this is
| actually practical 'advice'. I can't help but think most devs
| that want to use Jai are avoiding Rust purposefully so advising
| them to skip Jai as a potential replacement for their low level
| development needs and use Rust is just not going to happen.
| unwind wrote:
| As someone who is aware of jai but not at all following the
| development, do the terms of the closed beta the OP is in permit
| code to be shown?
|
| I guess "yes", it seems so pointless otherwise.
|
| Would be very interesting to see e.g. "here is how this (gnarly)
| C++ turned into beatiful jai", zoomed-in to actual code level.
| vinyl7 wrote:
| Yea, theres no NDA aside from not distributing the compiler.
| Theres a bunch of code on github, though it can be hard to find
| unwind wrote:
| Okay, great. That totally makes sense, but on the other hand
| Mr Blow seems to have some rather unusual ideas regarding how
| to develop this new language ( _and_ is a game developer,
| which sometimes brings its own set of secrecy-first ideas
| [1]).
|
| [1]: For reasons, of course. Been there.
| pietmichal wrote:
| Very interesting! Apparently a lot of information on the Internet
| about the Jai language is outdated which makes me curious about
| the follow up post!
|
| I don't know if OP is the blog owner. If yes, I'd love to have an
| option to subscribe to an email list. I've installed an RSS feed
| but email is still my preference. Thanks!
| dymk wrote:
| I don't understand how this language is planning on ever seeing
| adoption when it's been restricted from open use since it's
| inception. Seems like vaporware.
| diimdeep wrote:
| See https://github.com/Jai-Community/Jai-Community-
| Library/wiki/...
|
| and https://github.com/Ivo-Balbaert/The_Way_to_Jai
| DannyBee wrote:
| Your links back up the statement. The first says the compiler
| is proprietary and unavailable outside of some beta testers,
| but may be open in the great and nebulous future.
| p0nce wrote:
| > Supports x86 architecture only
|
| No native macOS then?
|
| > No virtual functions
|
| > Jai is less dogmatic
|
| okay
| Cyberdog wrote:
| > No native macOS then?
|
| Or Pi, or iOS, or practically all Android hardware... Kind
| of a non-starter IMO. Maybe this was marginally acceptable
| when the language started in '14 but it becomes less so
| every year.
| throwaway17_17 wrote:
| Blow is designing and implementing a language for making
| video games, and in particular, for making Thekla's video
| games (Jon's game company). Blow does not make mobile
| games, nor does he make small, retro-style games that
| would typically be run on a Pi. His concerns are modern
| Windows gaming PC's and the big three consoles. While Jai
| is Turing-complete and is 'general-purpose', the
| implementation serves Blow's needs first and fioremost,
| so the chosen targets make sense in light of that.
| naikrovek wrote:
| well, given that any random person can't just adopt the
| language today, the platform support available today
| doesn't really matter, does it?
|
| Jon is writing it for his needs, and this thread is full
| of people saying "it doesn't meet my needs!" So what?
| it's not _for you_!
| Cyberdog wrote:
| Yeah, I guess that's true as far as Blow goes. But there
| _are_ other people interested in this thing (hence why
| the OP exists and why we're commenting on it). And I
| presume not all of them want to lock themselves in to the
| apparent dead end that is the x86 platform in the current
| year when both cross-platform languages and cross-
| platform game engines are all over the place.
| dmitriid wrote:
| Given that he and his team are developing a language and
| a game in that language at the same time it makes sense
| to focus on the primary platforms they work on, and
| expect their game to currently run.
|
| Their primary platform is Windows, and the game in its
| current very early state is also running on Windows.
|
| What's the value in porting it to Raspberry Pi or
| Android?
|
| From the streams it looks like a Linux port is usually
| mostly up to date, and MacOS understandably lags behind.
| But neither of these platforms have any high priority for
| now.
| imran0 wrote:
| It has an LLVM backend so adding support for other
| architectures is not difficult.
|
| JB already ported the compiler to Nintendo Switch several
| years ago.
|
| https://old.reddit.com/r/NintendoSwitch/comments/cixsoy/j
| ona...
| mhh__ wrote:
| Most of the work is in the compiler's backend but you
| still need to set it up to generate the right object
| files and C ABI etc etc.
| typon wrote:
| Design by committee vs. design by singular vision is an age old
| debate. We have plenty of the former, why not give the latter a
| try? There are plenty of good languages out there already to
| use, why does this language have to aim for wide adoption?
| dboreham wrote:
| If you watch JB's videos (actually they're posted by someone
| else on YouTube I believe, taken from his Twitch streams), the
| language definitely exists.
| Cyberdog wrote:
| Maybe it's a marketing thing. Creating a perception of
| exclusivity. Making Jai the Maserati and Gucci of programming
| languages.
|
| That's ridiculous but seeing the odd level of interest in this
| language that almost nobody can use means maybe it's working.
| renox wrote:
| I agree that it's marketing but not for the 'exclusivity'
| reason, for the 'first impression' reason. You'll still hear
| quite often that DMD is proprietary or that there is no free
| Ada compiler even though this hasn't been true for many
| years..
| dottedmag wrote:
| It's "do I have bandwidth to deal with all the feature
| requests?" thing for now.
| doodpants wrote:
| I think Jonathan Blow's main goal is to make his dream game
| programming language so that he can be happier while developing
| all of his future games. Widespread adoption by others is only
| a secondary concern. He also doesn't want to push it out to the
| general public until he feels it's ready, and wants to take the
| time to get it right first.
| naikrovek wrote:
| Jonathan Blow is a skilled craftsman with stuff like this and
| he knows he's going to get a bunch of Opinions About His
| Language from people who think they have a complete superset
| of his knowlege, and he is making his language without
| involving those people in any way.
| klodolph wrote:
| That's fair, but if you look at his posts about the
| language, he also makes a big point about how he doesn't
| want any input from people with an academic background in
| language & type theory. This smells like anti-
| intellectualism to me.
|
| I'm a bit concerned that some of the decisions that he's
| making in the language are leading towards traps that have
| caught other language designers in the past, but because
| he's rejecting that expertise, he has to learn from
| experience, at greater cost. These concerns are motivated
| by specific things I've seen in Jai code, but I don't
| really want to dive into the specifics, since Jai is
| unavailable.
| cyber_kinetist wrote:
| I think his disdain towards academia isn't really anti-
| intellectualism (he's not ignorant of compiler theory
| knowledge, otherwise he wouldn't have been able to write
| a compiler from scratch in the first place! And his
| interest in programming languages seems to span decades,
| from what I remember from one of his streams). I think
| he's critical of the fact that the primary focus of
| academia and industry in computer science have diverged
| so much over the years, such that most academic CS works
| haven't really helped developers in building better
| programs and tools. Thinking about the countless hours
| compiler academics have spent on all sorts of esoteric
| parser theory in the past, while all the production
| compilers today are using recursive decent for pragmatic
| reasons... maybe this kinda makes sense.
| klodolph wrote:
| I'd have to say that academic research into programming
| languages has provided immense benefits for actual
| programmers over the years, it just has such a long lead
| time that people forget that the research came out of
| academia in the first place. People also don't really
| understand the process of how these ideas come from
| academia into mainstream programming languages.
|
| It only seems like academic research has diverged because
| the benefits of current research haven't materialized as
| real, usable features in programming languages that
| people use to get work done. But if you look at features
| that we use in day-to-day programming right now, you can
| trace the heritage of these features back to research
| programming languages (like Self or Haskell) and then
| farther back to more abstract research into esoteric
| subjects like category theory and substructural logic.
|
| The esoteric parsers that people invented in the past
| were, in a sense, necessary because people were ignorant
| of how to design languages in such a way that they could
| support a rich syntax without using a complicated parser.
| It took a lot of academic research for us to figure out
| that, say, you could probably use an LALR parser for lots
| of existing languages, and you could stick to LL(1) for
| new designs.
| cyber_kinetist wrote:
| That's a fair point. Maybe researchers _needed_ to delve
| into all sorts of weird parser theories, to later figure
| out that they weren 't that needed. Practicioneers mainly
| know the final result, but aren't usually interested in
| the full history of how people got to that conclusion.
|
| But I think during the recent decades, there has been a
| consensus that perverse incentives in academia are
| degrading research quality and preventing papers from
| becoming actually usable in real-life applications
| (mainly with the focus of paper metrics and the constant
| need to apply for grants). So although I think academia
| is still important long-term, I understand why some
| people would think it's becoming less useful.
| sph wrote:
| StevePerkins wrote:
| Over the past decade, I watched HN's and Reddit's hype waves
| cycle through server-side JavaScript, Golang, Haskell, and now
| Rust. With plenty of secondary favorites in the mix like Julia,
| Nim, Zig, etc.
|
| A lot of these things do find some modest niche to survive in.
| But none really take over the world as originally forecast by
| the hype wave.
|
| Ultimately, you either enjoy tinkering with programming
| languages for personal enrichment, or you do not. Hardly anyone
| is _actually_ using anything else at our Java /C#/Python/C++
| day jobs.
| thedracle wrote:
| I always look for practical application.
|
| I think cutting through the hype-train is something every
| engineer learns with time, but some times there are diamonds
| to be picked out.
|
| At least for my own anecdotal experience, Rust has lived up
| to a lot of the hype for the time-critical low-level projects
| I was formerly performing with C/C++.
| throwaway894345 wrote:
| Agreed, though I'm sad it isn't more often used. It's
| certainly picking up steam, but it seems to have a ways to
| go before it's going to be a serious contender for new
| projects in the embedded, video game, etc spaces where
| C/C++ still reign (by which I mean something like "before
| the majority of new projects are implemented in Rust").
| _aavaa_ wrote:
| While I agree with most of your points, I am not sure what
| this has to do with the parent you're replying to.
|
| The one part I disagree with is:
|
| > A lot of these things do find some modest niche to survive
| in. But none really take over the world as originally
| forecast by the hype wave.
|
| One of Blow's critique of C++ is _specifically_ that it 's
| trying to be the everything language. Jai's goal is to be for
| video game development, and that's it. Not for embedded
| systems, not kernels, not drivers, not high performance
| computing, not operating systems. Just video games.
| the__alchemist wrote:
| I was surprised to recently learn that embedded isn't on
| Jai's roadmap. I respect the decision re scope and feature-
| creep. It was surprising, given that usually languages with
| the performance, and low-level capabilities of C are also
| suited for embedded. Ie: The overlap with existing
| languages is almost 100% when you look at A: Languages that
| are fast/LL. B: Languages that are suitable for embedded.
| (The usual suspects of C, C++, Rust, Zig, and ADA)
| 4v0v wrote:
| It's false, he never said that it was only for games.
| Kranar wrote:
| I mean this is a little pedantic. It's true he never said
| that only games are able to use his language as if it
| were some kind of law, but he did say that his language
| is being designed to address issues that video game
| developers face and that was his main, and almost
| exclusively his only concern.
|
| If other domains benefit from that, he's not going to
| actively bar them from using his language, but he also
| won't give them much consideration.
| 4v0v wrote:
| It's just false, i'm in the closed beta and there are a
| lot of people that use it for other things than games.
| When they find a bug or have a suggestion he give them
| the same consideration as anyone.
| _aavaa_ wrote:
| What people use it for and what it's meant for are two
| different things.
| P5fRxh5kUvp2th wrote:
| But the decisions made are going to be for the benefit of
| game development first, and everything else secondarily.
| _aavaa_ wrote:
| Either the word "only" is doing a lot of heavy lifting in
| your sentence, or you're simply wrong [0].
|
| Yes you _could_ program anything in the language, just
| like you _could_ programming anything in any language.
| But he 's designing the language _for_ video game
| development. The whole reason he 's making it is
| specifically for video game development, and he's been
| very explicit that he believes that a language should
| _not_ try to be designed for use in every application.
|
| [0]: https://www.youtube.com/playlist?list=PLmV5I2fxaiCKf
| xMBrNsU1...
| [deleted]
| dymk wrote:
| I've also observed these waves, but never about a language
| that you can't actually go pick up a compiler or interpreter
| for. Jai is unique in that sense.
|
| Who's actually getting into these closed betas?
| 4v0v wrote:
| People that have an interesting projects for stress testing
| the langage.
| Keyframe wrote:
| Javascript absolutely took its position. Speaking of those
| waves, where did Ruby and RoR go? Seems completely dead on HN
| whereas 'back in the day' it was top most talked thing. LISP
| would be a guest of honor - always there, never here.
| TomBombadildoze wrote:
| Ruby/RoR values form over function. Over the past few (five
| or so?) years, as teams went through the transition from
| aggressive feature development to devoting more effort to
| maintenance and operations, they realized that relying on
| conventions as a guiding principle has a substantial cost
| burden that you don't pay when prefer rigor and
| specification.
| klodolph wrote:
| I think Ruby and RoR just didn't quite survive the
| transition to much heavier client-side JavaScript apps.
| Ruby peaked sometime around 2009 and back then, the browser
| landscape was much more diverse, and it was common to
| support IE6. It's easy to forget how much of a burden IE6
| was on web developers.
|
| Ruby also suffered from a proliferation of ill-advised
| programming practices (monkey patching) and there was also
| some drama in the Ruby community (Rails Is a Ghetto). These
| were fixable problems and the Ruby community took steps to
| stop monkey patching everything and maybe address the other
| problems, but in the end, I think would-be Rails developers
| started using Node.js, and Ruby fell from the public
| spotlight.
|
| As far as I can tell, Python survived by virtue of tools
| like NumPy, SciPy, Pandas, PyTorch, OpenCV, etc. Kind of a
| universal glue language for people who don't want to write
| C or C++. Otherwise, I think of Python and Ruby (as
| languages) as nearly interchangeable. Python had its own
| issues to work through (2 -> 3) and its own drama, but it
| settled in some more stable niches and seemed to have fewer
| mercurial personalities at the center of it all.
| mlyle wrote:
| I'm starting to actually believe that Rust will eat C's lunch
| for systems programming.
| bsder wrote:
| Rust will not accomplish this without significant language
| changes as well as changing cargo into something a lot more
| cooperative with external ecosystems.
|
| Zig is getting an absolutely enormous boost from the fact
| that it is a self-contained C ecosystem that can cooperate
| with others. Zig has tripped into a very powerful niche--a
| lot of people _LOATHE_ the build systems of the C /C++
| world. If Zig gains very much more traction there, it's
| going to be _extremely_ hard to dislodge.
|
| I suspect that there are _FAR_ more users of "Zig as C
| build system" than there are of "Zig as a language".
| pjmlp wrote:
| Lets see if it has better luck than C++ on domains that
| don't care about anything beyond C89, and compiler
| extensions.
| zppln wrote:
| People have been believing that for close to a decade now.
| mlyle wrote:
| Yup, and it keeps steadily winning a small stream of
| converts and additional projects from C.
|
| So I didn't believe it before, but it's starting to seem
| more plausible.
|
| Of course, it'll take a very long time. There's a _lot_
| of C code out there. :D
| [deleted]
| dymk wrote:
| And now there's Rust in the Linux kernel
| cyber_kinetist wrote:
| I think there is a space for other alternative low-level
| languages that aren't that strict about compile-time safety
| though (Zig, Jai, Odin), that Rust cannot capture.
|
| Many proclaim that compile-time safety using type theory is
| the only way to create reliable low-level software, but I
| think it can alternatively be done with good data structure
| design and various compiler tooling that instead catch
| these errors at runtime (generational indices/references,
| Address Sanitizer, and recently Zig's safety mode). We need
| to explore multiple directions to really solve the memory
| safety problem, and I don't think Rust is the _only_ way
| (although it is a _viable_ way, proven by some recent
| successful applications).
| jimbob45 wrote:
| The disparity between Rust jobs and C/C++/C#/Java/Golang
| jobs on Indeed is staggering. Even worse, most of the Rust
| jobs are blockchain-related and may not survive the coming
| blockchain downturn.
|
| It may be the case that some people use Rust but without
| Rust jobs, there will be no pool of experienced developers
| to later draw on.
| stackbutterflow wrote:
| Hasn't the downturn already happened?
| mlyle wrote:
| > The disparity between Rust jobs and
| C/C++/C#/Java/Golang jobs on Indeed is staggering.
|
| Most of the world are things other than real systems
| programming. C++/C#/Java/Golang are likely better choices
| for this than either C or Rust.
|
| But a C-like language is necessary. Rust may be (very
| slowly) displacing C for systems programming.
|
| As you mention, it takes awhile for the pool of
| experienced developers to show up.
| 0x445442 wrote:
| You don't think JavaScript is widely used in day jobs?
| the_only_law wrote:
| Go as well seems to be pretty big nowadays.
| throwaway894345 wrote:
| I don't think Go was ever especially over-hyped, and it has
| been pretty wildly successful in its "niche" (server side
| programming, CLI tools, daemons, etc). There was some
| controversy because someone said it was for "systems
| programming" by which the author seems to have meant
| "distributed/networked systems" rather than "operating
| systems" or whatever most people mean when they use the (very
| imprecise) term "systems programming".
|
| And to that extent, Go has been very successful (virtually
| the entire container ecosystem and a good chunk of the
| broader cloud ecosystem). It is doing a lot of stuff that
| would have previously been in Java or C# or Python or Node or
| Ruby (contrary to your "hardly anyone is actually using
| anything else..." remark).
|
| Of course, older languages are naturally going to have more
| jobs because there's an enormous volume of legacy code that
| can't be cheaply translated to a new language, but so you
| have to look at the distribution of languages among _new_
| projects to be able to even begin making reasonable
| comparisons between languages, and even then a historically
| Java shop is probably going to give a ton of preference to
| Java, so here too we see a lot of weight given to older
| languages irrespective of their merit.
| typon wrote:
| "virtually the entire container ecosystem"
|
| An entire area of software that is completely unnecessary,
| but because the gods at Google gifted it to us, people have
| to pretend it's amazing
| throwaway894345 wrote:
| Of course, this is nonsense and people use containers
| because they deliver real value, not because of Google
| marketing or name recognition (most don't even know
| containers come from Google, but would likely attribute
| them to Docker). I'm not a container purist--eventually
| micro VMs and unikernels will eat a lot of their market
| share (that's my prediction, anyway), but until we get
| there containers are invaluable and criticism like yours
| is devoid of substance.
| gizmo wrote:
| The other niche languages are either buggy, slow, or both. Jai
| won't be. Ultimately it's about taste and quality. If the
| language gets enough right then people will switch to it,
| because people are desperate for a c++ alternative. Open
| sourcing or early access won't help here. Somebody just has to
| do the hard work of writing the compiler internals, and it will
| be done when it's done. And really, I wouldn't bet against
| somebody who has delivered on big projects twice before.
| overgard wrote:
| I'm not sure Blow cares that much about widespread adoption; he
| seems more concerned with quality. Personally I'd love an open
| beta, but I can understand why he might want to reserve the
| right to make drastic changes to the language before he
| releases it.
| tonetheman wrote:
| Hard to get much out of this since the language is not available
| to everyone.
| flykespice wrote:
| I heard about this "promising" language as a youngster and never
| heard of it again, it doesn't seem to have taken off after all
| these years, and probably it's too later for it ever take off.
| poulpy123 wrote:
| I'm not sure that if passing from a widely used language to a
| marginal language wasn't a success why going from a marginal
| language to a totally obscure one will be
| bachmeier wrote:
| > there's also the general feeling that the D creators' vision of
| what a fixed C++ looks like is just vastly different from mine
|
| I have emphasized for years that D is not C++. It can be used as
| a replacement for C++, in the sense that it does the same things,
| but it is not accurate to call it a "fixed C++". So many times I
| have seen C++ programmers disappointed that D is not C++. On the
| other hand, if you're a C programmer, you'll probably be
| comfortable writing D code. I think of D and C++ as incompatible
| forks of C.
| didip wrote:
| This person might as well said that he is not planning to finish
| his game.
|
| Screwing around with tooling and languages seems to be a common
| pitfall to not finishing a game.
|
| Why not just use the best ecosystem like Unreal/Unity and get the
| game out of the door fast?
| phendrenad2 wrote:
| > get the game out of the door fast
|
| But at what cost? Using Unity/Unreal incur the cost of lower
| flexibility in your design, more time spent learning "the
| unreal way"/"the unity way", and a finished product that looks
| and feels like every other unity/unreal game.
|
| Of course the argument for unity/unreal is also true: Building
| your own game engine takes lots and lots of time.
|
| So it's a tradeoff, like all things.
| markdog12 wrote:
| > And the most important reason: I just feel like it!
| actuallyalys wrote:
| Rewrites in whatever language or tool catches your eye are a
| common pitfall (although you often learn a lot in the process),
| but moving to Unity would also be a rewrite. It might be a
| harder rewrite, in fact, because the author would have to adapt
| to a new language and a new engine. They might be able to use
| Unity features instead of rewriting some code but they'd still
| have to figure out how to use those features.
| cyber_kinetist wrote:
| I think for the type of game that he's working on ("a 2D
| physics sandbox game that lets you explore the galaxy"), a
| custom handmade engine might be far better than using one of
| the mainstream game engines. His game is in 2D, so the shiny 3D
| renderers that Unity and Unreal have won't really matter that
| much. And his game seems to contain lots of performance-
| sensitive physics and geometry code that needs to be tailor-
| made to his game, so the default solutions in Unity and Unreal
| will be probably be unusable (so they would need to be written
| from scratch anyway). The goal he's setting for is very
| ambitious even for a 2D game, and Unity/Unreal will probably
| limit him too much.
|
| That said, I think many of the decisions towards his rewrite in
| Jai seems to come from him picking the wrong language (D) at
| the start. He should have sticked with C++ in the first place,
| even with all its warts and complexities. It's a proven
| language that has shipped countless games, have tons of tooling
| developed around it, and provides one of the biggest ecosystems
| available to a game developer (and unlike D, has debuggers that
| actually work!). And you can certainly improve compile times a
| lot by using unity builds, managing your header dependencies
| well, and not going too overboard with templates (though I
| agree this can become a major pain point, especially if you're
| using a laptop).
| naikrovek wrote:
| > Why not just use the best ecosystem like Unreal/Unity
|
| laughable. absolutely laughable.
|
| I'm not even talking about politics of using an engine versus
| writing one; unity and unreal are complex tools with their own
| problems. if you value what you are producing, and if you value
| quality and you want your game to be just the way you want it,
| Unity and Unreal will fight you just as hard as D or C++ have
| been for the blog author.
|
| Unity/Unreal are also simply not capable of a lot of things.
| They are _definitely_ not a pure win for someone making a game.
| nomel wrote:
| Could you give an examples of a game that used a custom game
| engines that couldn't achieve what they wanted in Unreal or
| Unity?
|
| Edit: The only style I would think would be infinite/strange
| geometry, like Manifold garden (great game!). But, it's
| Unity.
| jessermeyer wrote:
| I've worked on several. You haven't heard of them because
| none of them shipped due to issues with commercial engines
| (in particular Unreal Engine 4).
|
| They are very difficult to use if the game play semantics
| are complicated and require lots of interaction with world
| state or world geometry. If you're making a common FPS,
| they are great.
| [deleted]
| mrtweetyhack wrote:
| klodolph wrote:
| > laughable. absolutely laughable.
|
| It's really not laughable.
|
| I've made games with off-the-shelf engines and I've made
| games using just code and libraries. Sometimes not even
| libraries.
|
| The main concern here is that you have a limited amount of
| time to work on your game. Some people try to sidestep this
| concern by saying that they'll "spend as much time as it
| takes" or something like that, but since these projects often
| fail due to attrition, I'm skeptical.
|
| Engines like Unity and Unreal have plenty of constraints and
| they fight you, but you don't have to fight them unless you
| have powerful, immovable, inflexible opinions about how the
| game code should be implemented. Otherwise, these engines
| give you a surprising amount of freedom. This freedom is not
| apparent to casual users of the engines and it's not apparent
| if you read forums explaining how these engines are used.
|
| > They are definitely not a pure win for someone making a
| game.
|
| Sure. Not a pure win. In some sense, however, time is
| interchangeable with time. By choosing an engine like Unity
| or Unreal, you save some time in some areas of the project,
| and that time can be reinvested in other parts of your
| project. You end up with a higher-quality game in the same
| amount of time, in typical scenarios. Or you end up with a
| similar-quality game in a smaller amount of time, in typical
| scenarios.
| cyber_kinetist wrote:
| If the game was a more typical 3D action-adventure or
| FPS/TPS shooter, then using one of the two engines might
| have been _much_ better for development time. But this is a
| complex 2D sandbox simulator with procedural generation and
| a custom physics engine, so I 'm not sure how Unity or
| Unreal might aid in developing this game in any way.
| klodolph wrote:
| I'll pick Unity to talk about here, because I have the
| most experience with Unity.
|
| I've gone in more depth discussing Unity "off the beaten
| path" before and I think people really overestimate how
| much you are constrained by the way Unity works. This
| applies both to seasoned Unity developers and to people
| who only take a quick look at Unity.
|
| I claim,
|
| - You can use your own physics engine with Unity,
|
| - You can model entities however you want with Unity,
| even not modeling them as GameObject instances containing
| MonoBehaviour components,
|
| - It is completely reasonable to develop an actual, real
| game this way, under realistic staff / expertise /
| schedule / budget constraints. (In fact, it is known that
| certain successful commercial games do this.)
|
| Just to focus on a more specific example--let's say you
| need your own physics engine. What's an easy way to do
| that? Create your physics engine, and have it control the
| positions of Unity GameObject instances. This way you can
| easily set up test scenes in the Unity editor and see the
| results by hitting "play".
|
| Unity gives you this fantastic GUI for setting up these
| test scenes and a renderer you can use to visualize your
| physics engine behavior.
|
| This is really not "abusing" the Unity engine in any way.
| The engine provides physics simulation, but it does not
| force you to use it.
|
| Likewise--I've written games in Unity that do a lot of
| procedural generation, and I've written games without an
| off-the-shelf engine that do procedural generation. There
| are a lot of things that make it easier in Unity, and I'm
| not spending as much time fussing about with builds, or
| dealing with input, or figuring out how to port my game
| to other systems. Unity provides an API for me to create
| a mesh at run-time. During procedural generation, I
| generate the meshes for generated chunks of terrain, and
| the data structures look very similar to the way I would
| have written the data structures in my own engine.
| cyber_kinetist wrote:
| Since you seem to have much more experience in developing
| games, I'll take most of your word here.
|
| Though from my four years of experience in Unity (albeit
| at a non-professional level), I was always fighting with
| the engine when trying to build new things. Trying to
| build complex UI code using Unity's built-in system was a
| mess, the serialization system always had weird errors
| and didn't really work well with version control, adding
| custom rendering to the rendering engine was full of
| hacks, and the documentation was quite poor for the more
| obscure/hidden aspects of the engine up to the point that
| I was thinking "I can just write these in C++/OpenGL, why
| do I have to go through all of this crap?". Nowadays I do
| gamedev at a lesser capacity (and doing more general
| graphics programming in C++ instead), and since several
| years ago I haven't really looked too deeply into the
| engine. I think doing all of these in Unity isn't
| _impossible_ , just that I'm expecting a lot of friction
| while doing it.
|
| There always seems to be some really good indie
| developers who are stretching Unity to its limits though
| (such as Manifold Garden). I always wondered how much
| they were fighting with the engine to make some specific
| features.
| klodolph wrote:
| Yes, I think about Manifold Garden a lot when talking
| about limitations in the Unity engine.
|
| There definitely _are_ limitations in the render
| pipeline, and I've spent time frustrated because I know
| how to do something in OpenGL but can't figure out how to
| do it in Unity. But the rendering pipeline in Unity has
| become far more flexible in recent years, and you can
| make your own custom rendering pipeline. Look up "custom
| SRP" videos on YouTube if you want to see what that's
| like. Here's one such video:
| https://www.youtube.com/watch?v=91zUwJwkXNQ
|
| I do remember serialization + version control problems
| long ago, but these days, serialization uses a text
| format by default and if you are sufficiently adventurous
| you can solve merge conflicts in your serialized data.
| Better to avoid merge conflicts in the first place,
| though.
| skohan wrote:
| "Kitchen Sink" engines like Unreal and Unity come with their
| own set of assumptions which may or may not help to deliver a
| given game. If you want to make a game which is radically
| different than the industry standard, you're going to have to
| spend a lot of time working around those baked-in assumptions,
| and it may be more efficient to choose another approach.
| zero_iq wrote:
| Ironically, Unreal Engine was in large part born from Tim
| Sweeney's "screwing around with tooling and languages".
|
| UnrealScript has long been dropped in favour of C++, but I'm
| pretty sure Unreal Engine wouldn't exist today, or would be a
| very different beast, if it hadn't been for UnrealScript and
| the Unreal Editor being bundled with the original Unreal and
| its sequels/follow-ups, and Tim's personal interest and
| research into how programming languages might improve game
| development, in much the same way that Jonathan Blow is doing
| now.
|
| Can I assume your use of the phrase "this person" means you are
| unfamiliar with Mr Blow, and his track record in game
| development? You might want to look him up -- he's an
| interesting character and has developed some interesting and
| influential games.
| 0xffff2 wrote:
| >Can I assume your use of the phrase "this person" means you
| are unfamiliar with Mr Blow, and his track record in game
| development?
|
| Not OP, but I'm fairly sure "this person" refers to the blog
| post author, not JB.
___________________________________________________________________
(page generated 2022-11-23 23:01 UTC)