[HN Gopher] Adobe Photoshop 1.0 Source Code (1990)
___________________________________________________________________
Adobe Photoshop 1.0 Source Code (1990)
Author : tosh
Score : 401 points
Date : 2025-12-18 15:37 UTC (5 days ago)
(HTM) web link (computerhistory.org)
(TXT) w3m dump (computerhistory.org)
| roschdal wrote:
| Gimp source code: https://gitlab.gnome.org/GNOME/gimp
| KellyCriterion wrote:
| the funny thing with GIMP is: even while its a very powerful
| tool, it still lacks a good texting tool until today :-)
|
| and having the source available didnt help so far either :-))
| panki27 wrote:
| Nothing stops you from creating a PR :-)))
| KellyCriterion wrote:
| I would, if I would GIMP use often enough to have the
| motivation - I use GIMP maybe 2 - 3 times a year.
|
| And thats the irony covered in my post: Even that the
| source is available didnt motivate someone enough so far to
| create better version of the built
| worldsavior wrote:
| Nothing stops you from commenting these useless comments.
| KellyCriterion wrote:
| for the downvoters:
|
| could you please show me a good textting tool plugin for
| GIMP, then?
|
| you can check their forums & other sites: the textingtools is
| on top of their discussion lists?
| shakna wrote:
| I don't see it at the top of the discussion on the forums I
| checked.
|
| So can you expand why you think the text tool, is bad?
| KellyCriterion wrote:
| Before release 3.0:
| https://discuss.pixls.us/t/gimp-3-0-will-the-text-tool-
| be-im...
|
| Reddit: https://www.reddit.com/r/GIMP/comments/1fecr6u/su
| ggestion_im...
|
| Its just the first two results from top of Google.
|
| Maybe the tool was improved in version 3.0, I'm running
| an older 2.x version. I will check it next time.
|
| The versions were difficult in: - font size applying -
| random loss / reset settings - there were some issues
| with the preview when editting - font preview before
| selection etc.
| shakna wrote:
| Both of those are from over a year ago? For future, I
| wouldn't think that's "top" of any discussion.
|
| The strange font sizes and setting reset was mostly fixed
| as part of the 2020 massive refactor [0]. There are still
| some minor inconsistencies between the two font editor
| panels, but they're being worked on.
|
| Thankfully, you shouldn't have any random setting changes
| since about 2018 build.
|
| [0] https://gitlab.gnome.org/GNOME/gimp/-/issues/344
| ehnto wrote:
| Honestly, I think it was just the smiley faces. I didn't
| downvote.
| hiccuphippo wrote:
| I don't understand what you mean by texting tool. Do you
| mean text rendering? kerning?
| postexitus wrote:
| Can you detail what you mean by good texting tool? What
| features are missing?
| RadiozRadioz wrote:
| For texting I recommend using a mobile phone or desktop
| instant messaging program. While it's not the case with all
| of them, graphics editing tools tend to have texting
| utilities as a second-class citizen at best
| KellyCriterion wrote:
| haha, good one :-D ;-) ;-)
| dist-epoch wrote:
| FTFY: the funny thing with GIMP is: even while its a very
| powerful tool, it still lacks a good image editing tool until
| today
| rplnt wrote:
| I used to use GIMP as an example of OSS desktop applications
| having bad UX, I mean back around 2010 maybe. The UX felt plain
| horrible. Anything I every tried there was pain to achieve. And
| there was plethora of desktop applications having the same
| issue back then. "Geeks can't do UI".
|
| I feel like that has changed? Even Blender felt good the last
| time I used it, Firefox became kinda fine, though these are
| probably bad examples as they are both mainstream software. But
| what about OSS that is used primarily by OSS enthusiasts? What
| about GIMP now?
| VoidWhisperer wrote:
| This is just my personal experience, but even with the
| current UI, there can tend to be a learning curve with GIMP.
| Alot of it probably comes from figuring out where tools and
| functionality that are readily available upfront in other
| paint programs are hidden 2-3 menus deep in GIMP
| cynicalsecurity wrote:
| A simple trick to make GIMP perfectly usable (exists since
| ages):
|
| > To change GIMP to single-window mode (merging panels into
| one window), go to "Windows" in the top menu and select or
| check "Single-Window Mode"; this merges all elements like the
| Toolbox, Layers, and History into one unified view.
| tonyedgecombe wrote:
| Blender feels like an outlier amongst open source software.
| Outside of programmers tools the great majority of open
| source feels mediocre. I wonder what the Blender people did
| differently.
| Palomides wrote:
| unlike most FOSS, blender gets millions of dollars a year
| to support development
| maxloh wrote:
| That's what happens when you let people do other people's
| jobs. UI/UX design is a profession, and there is a reason for
| that.
|
| Unfortunately, designers are rare among the FOSS community.
| You can't attract real casual or professional users if you
| don't recognize the value of professional UI/UX.
| voidUpdate wrote:
| I've never understood the negative comments around UX for
| GIMP. It always feels just fine for me. Some stuff is in
| menus, but its a complex application with a lot of parts so I
| understand that
| trinix912 wrote:
| GIMP in my opinion has a very good UI when you're looking at
| graphics as a programmer: threshold this, clamp that, apply a
| kernel ("custom filter")... Everything seems to click with a
| mental model of someone who does graphics programming.
|
| Whereas Photoshop and other "mainstream" software use terms
| and procedures non-programmers are more likely to be familiar
| with: heal this area with a patch, clone something with a
| clone stamp, scissors/lasso to cut something out (not saying
| GIMP doesn't have those)...
| GaryBluto wrote:
| GIMP is an excellent example of the shortcomings of FOSS,
| considering that it first released in 1998 and almost 27 years
| later still does not have feature parity with Photoshop 6.0.
| Daneel_ wrote:
| Interesting little read. I always find it fascinating when old
| code holds up really well - especially structurally. Great trip
| down memory lane!
| ofalkaed wrote:
| When this got released I really expected someone in the
| opensource community to run with it, but as far as I know no one
| has. Back around 1990 a Graphic designer that had his office n
| the same building as my mom worked in let me copy his Photoshop
| 1.x disks and nothing has ever compared to it for me. When will
| we get the linux port of Photoshop 1.0? I would love to see how
| it develops.
| delaminator wrote:
| If they did, they can only send you screenshots
|
| > 2. Restrictions. Except as expressly specified in this
| Agreement, you may not: (a) transfer, sublicense, lease, lend,
| rent or otherwise distribute the Software or Derivative Works
| to any third party; or (b) make the functionality of the
| Software or Derivative Works available to multiple users
| through any means, including, but not limited to, by uploading
| the Software to a network or file-sharing service or through
| any hosting, application services provider, service bureau,
| software-as-a-service (SaaS) or any other type of services. You
| acknowledge and agree that portions of the Software, including,
| but not limited to, the source code and the specific design and
| structure of individual modules or programs, constitute or
| contain trade secrets of Museum and its licensors.
| ofalkaed wrote:
| I was talking about more than just a literal port, running
| with it is broader than just a literal port. I guess my
| general point is that I am disappointed that all these
| releases of historical code have so little to show for being
| released.
|
| Edit: Disappointed is really not the right word but I am
| failing at finding the right word.
| pm215 wrote:
| I think there's two parts to this:
|
| 1) these historical source code releases really are largely
| historical interest only. The original programs had
| constraints of memory and cpu speed that no modern use case
| does; the set of use cases for any particular task today is
| very different; what users expect and will tolerate in UI
| has shifted; available programming languages and tooling
| today are much better than the pragmatic options of decades
| past. If you were trying to build a Unix clone today there
| is no way you would want to start with the historical
| release of sixth edition. Even xv6 is only "inspired by"
| it, and gets away with that because of its teaching focus.
| Similarly if you wanted to build some kind of "streamlined
| lightweight photoshop-alike" then starting from scratch
| would be more sensible than starting with somebody else's
| legacy codebase.
|
| 2) In this specific case the licence agreement explicitly
| forbids basically any kind of "running with it" -- you
| cannot distribute any derivative work. So it's not
| surprising that nobody has done that.
|
| I think Doom and similar old games are one of the few
| counterexamples, where people find value in being able to
| run the specific artefact on new platforms.
| delaminator wrote:
| you literally said:
|
| > When will we get the linux port of Photoshop 1.0?
| ndiddy wrote:
| What would you expect to happen? Photoshop 1.0 is an almost
| unusably basic image editor by modern standards. It doesn't
| even have layers (they were introduced with Photoshop 3.0 4
| years later). Even if the code was licensed in a manner
| that allowed distribution of derivative works (which it
| isn't), it's written in Apple's Pascal dialect from the
| mid-80s and uses a UI framework that's also from the
| mid-80s and only supports classic Mac OS. CHM didn't even
| release the code in a state that could be usable out of the
| box if you happen to have a 40 year old Macintosh sitting
| around. Here's a blog post showing how much work it took
| someone to compile it: http://basalgangster.macgui.com/Retr
| oMacComputing/The_Long_V...
|
| I think Adobe decided to release the code because they knew
| it was only valuable from a historical standpoint and
| wouldn't let anyone actually compete with Photoshop. If you
| wanted to start a new image editor project from an existing
| codebase, it would be much easier to build off of something
| like Pinta: https://www.pinta-project.com/
| somat wrote:
| It would be trivial to distribute a patch and a link to the
| original source. The patch can be distributed under whatever
| license the author wants. The resulting binary then becomes
| an unlicensed derivative work, the person who compiled it can
| use it however they want but are not allowed to legally
| distribute it.
|
| My personal thoughts are: open-source software is great,
| probably the ideal condition, but I wish the general software
| distribution environment was not effectively all or nothing.
| open-source or compiled binary. I wish that protected-source
| software was considered a more valid distribution model.
| where you can compile, inspect fix and run the software but
| are not allowed to distribute it. Because trying to diagnose
| a problem when all you have is a compilation artifact is a
| huge pain. You see some enterprise software like this but for
| the most part it either open-source or no-source.
|
| I am a bit surprised that there is no third party patch to
| get photoshop 1.0 to run under modern linux or windows, not
| for any real utility(at this point MS paint probably has
| better functionality), but for the fun of it. "This is what
| it feels like to drive photoshop 1"
| msk-lywenn wrote:
| The source is now readable but it's not open source at all.
| bromuro wrote:
| It is open source but not free software.
| cgfjtynzdrfht wrote:
| It's "source available" [1], not open source [2].
|
| Words have meaning and all that.
|
| 1: https://en.wikipedia.org/wiki/Source-available_software
|
| 2: https://en.wikipedia.org/wiki/Open_source
| geokon wrote:
| cant blame him. We're in a bit of a bananas situation
| where open source isnt the antonym of closed source
| jefftk wrote:
| This isn't that uncommon:
|
| * If a country doesn't have "closed borders" then many
| foreigners can visit if they follow certain rules around
| visas, purpose, and length of stay. If instead anyone can
| enter and live there with minimal restrictions we say it
| has "open borders".
|
| * If a journal isn't "closed access" it is free to read.
| If you additionally have permissions to redistribute,
| reuse, etc then it's "open access".
|
| * If an organization doesn't practice "closed meetings"
| then outsiders can attend meetings to observe. If it
| additionally provides advance notice, allows public
| attendance without permission, and records or publishes
| minutes, then it has "open meetings."
|
| * A club that doesn't have "closed membership" is open to
| admitting members. Anyone can join provided they meet
| relevant criteria (if any) then it's "open membership".
|
| EDIT: expanded this into a post:
| https://www.jefftk.com/p/open-source-is-a-normal-term
| denotational wrote:
| * A set that isn't open isn't (necessarily) closed.
|
| * A set that is open can also be closed.
| nothrabannosir wrote:
| _> Words have meaning and all that._
|
| Ironic put down when "open source" consists of two words
| which have meaning, but somehow doesn't mean that when
| combined into one phrase.
|
| Same with free software, in a way.
|
| Programmers really are terrible at naming things.
|
| :)
| thayne wrote:
| Even without a specific definition for "open source", I
| wouldn't consider source code with a restrictive license
| that doesn't allow you to do much with it to be "open".
| chongli wrote:
| No, it's source available but not open source. Open source
| requires at minimum the license to distribute modified
| copies. Popular open source licenses such as MIT [1] take
| this further:
|
| _The above copyright notice and this permission notice
| shall be included in all copies or substantial portions of
| the Software._
|
| This makes the license transitive so that derived works are
| also MIT licensed.
|
| [1] https://en.wikipedia.org/wiki/MIT_License?wprov=sfti1#L
| icens...
| aeon_ai wrote:
| MIT is not copyleft. The copyright notice must be
| included for those incorporated elements, but other
| downstream code it remains part of can be licensed
| however it wants.
|
| AGPL and GPL are, on the other hand, as you describe.
| chongli wrote:
| Modifications _can_ be licensed differently but that
| takes extra work. If I release a project with the MIT
| license at the top of each file and you download my
| project and make a 1-line change which you then
| redistribute, you need to explicitly mark that line as
| having a different license from the rest of the file
| otherwise it could be interpreted as also being MIT
| licensed.
|
| You also could not legally remove the MIT license from
| those files and distribute with all rights reserved. My
| original granting of permission to modify and
| redistribute continues downstream.
| sigseg1v wrote:
| Not quite. You need to include the MIT license text when
| distributing the software*, but the software you build
| doesn't need to also be MIT.
|
| *: which unfortunately most users of MIT libraries do not
| follow as I often have an extremely difficult time
| finding the OSS licenses in their software distributions
| phendrenad2 wrote:
| No, the original definition of open-source is source code
| that is visible (open) to the public.
| Xerox9213 wrote:
| It's is "source available" but not open source.
| ptx wrote:
| Open Source is the same thing as Free Software, just with
| the different name. The term "Open Source" was coined later
| to emphasize the business benefits instead of the rights
| and freedom of the users, but the four freedoms of the Free
| Software Definition [1] and the ten criteria of the Open
| Source Definition [2] describe essentially the same thing.
|
| [1] https://www.gnu.org/philosophy/free-sw.en.html
|
| [2] https://opensource.org/osd
| ofrzeta wrote:
| You could try having an LLM port it to Linux :) As an aside I
| was always (well, no longer) hoping that Photoshop gets ported
| to Linux because at least an IRIX port existed, so there has to
| be some source code with X11 or whatever library code.
|
| https://fsck.technology/software/Silicon%20Graphics/Software...
| robert-brown wrote:
| Photoshop was ported to IRIX using Latitude, Quorum
| Software's implementation of Mac OS System 7. Apple later
| acquired the Quorum's code and it became part of Carbon.
| anthk wrote:
| There's System 7 for Unix 'natively', with either Executor
| (there's a fork under Github) or some other project:
| https://www.v68k.org/advanced-mac-substitute/
|
| https://github.com/autc04/executor
|
| https://github.com/jjuran/metamage_1/
| jeffrallen wrote:
| As an experiment, I gave the source zip file to Claude and
| told it to make a WASM version of the app, by translating the
| Pascal to Go.
|
| It nailed it, first try.
|
| I cannot, unfortunately, share a link to the website it
| created because of the license.
|
| LLM translations of historical software to modern platforms
| is a solved problem. Try it, you'll see.
|
| I used https://exe.dev/ and their Shelley agent to drive
| Claude. Give it a try, it is jaw dropping.
| ndiddy wrote:
| Can you post a video demonstrating you using it?
| jeffrallen wrote:
| https://exe.dev has a nifty private sharing feature,
| contact me in email and you can see it.
| nxobject wrote:
| That's a bit of an extraordinary claim: what did Claude do
| about the important non-Pascal parts: the resource fork and
| the 68k assembly?
| jeffrallen wrote:
| Look I understand it's crazy, but it took one small
| prompt and I came back a half hour later expecting it to
| have given up, but instead I saw exactly what you'd
| expect to see in my browser.
|
| Here is the prompt I gave it:
|
| "Use wasm and go and a 68000 emulator to get the
| Photoshop 1.0.1 software at https://d1yx3ys82bpsa0.cloudf
| ront.net/source/photoshop-v.1.0... to run correctly. You
| should not require an operating system, instead implement
| the system calls that Photoshop makes in the context of
| wasm. Because Go compiles to wasm, you might try writing
| some kind of translator from the pascal to go and then
| compile for wasm. Or you might be able to find such a
| thing and use it."
|
| You can give it a try yourself, or contact me for a
| private link to it (see the CHM license for why I can't
| make it public).
| anthk wrote:
| If it uses Motif and IrisGL (now MESA3D) the amount of
| porting effort it's near NIL.
|
| And, for purity/completeness, avoid Maxx Desktop and/or
| NSCDE; EMWM with XMToolbar it's close enough to SGI's Irix
| desktop.
|
| https://fastestcode.org/emwm.html
| LollipopYakuza wrote:
| I understand it was a very unique and powerful piece of
| software in 1990 but why would it be such a game changer to
| have the 1.0 running on Linux today?
| gwbas1c wrote:
| What about GIMP or any of the other open source image editors?
|
| Just supporting a modern OS's graphical API (The pre-OSX APIs
| are long dead and unsupported) is a major effort.
| reconnecting wrote:
| There was something magical about white floppies, as shown in the
| screenshot.
| apples_oranges wrote:
| you mean photo not screenshot.
|
| I think all floppies are magical :)
| reconnecting wrote:
| Image.
|
| Back in time, black were ordinary, and only white/grey ones
| were for licensed software, thus more desirable.
|
| https://computerhistory.org/wp-
| content/uploads/2019/08/photo...
| 10729287 wrote:
| The same for cameras back in the 60s/70s. Silver was the
| norm, black was way more desirable. Funnily it's now the
| opposite.
| achairapart wrote:
| As I remember, the blue ones where the most ordinary (and
| boring), at least for 31/2-inch size. For 51/4-inch, they
| were mostly black, but I remember some of them in colors
| too (especially orange or yellow ones, they were
| beautiful).
|
| E.g: https://c7.alamy.com/comp/2AA9BC4/ajaxnetphoto-2019-wo
| rthing...
| reconnecting wrote:
| White gold:
| https://archive.org/download/windows-3.00a/media-
| disk01.png
| spacebacon wrote:
| That software box on the shelf at Babbage's is a cherished memory
| --a tangible oddity of software distribution prior to broadband,
| now just a relic in memory. Most of us assumed it would last
| forever. We get our software at the click of a button now, but we
| traded something for that.
| xnorswap wrote:
| Software felt more valuable when you forked over PS60+ ( Which
| was worth a lot more back then ) and got a physical box, with a
| chunky set of instruction manuals and 5+ floppy disks.
|
| It wasn't even broadband that destroyed that experience, when
| CDs came around developers realised they had space to just
| stick a PDF version of the manual on the CD itself and put in a
| slip that tells you to stick in the CD, run autorun.exe if it
| didn't already, and refer to the manual on the CD for the rest!
| ofrzeta wrote:
| Manuals like AutoCADs have certainly felt valuable
| https://i.ebayimg.com/images/g/Gm8AAeSwwIZowjzn/s-l1600.jpg
| It's not even complete, for instance the ADS manual is
| missing. It's also a bit more expensive with roughly 3700 USD
| in 1992.
| xnorswap wrote:
| Oh yeah, when I said PS60, I was thinking of even the
| cheapest consumer-grade software!
| antod wrote:
| Whoa strong nostalgia hit from that photo. I seem to
| remember the R13 (the last version I used before shifting
| into tech) stack of manuals was even bigger.
|
| The Office 4.3 set of manuals were large too, but didn't
| have the information density the AutoCAD ones did.
| flyinghamster wrote:
| Also, you were far more likely to get actual documentation
| back in the day. You're never going to get a detailed first-
| party technical reference for today's Apple computers (at
| least not without being Big Enough and signing a mountain of
| NDAs); compare that to the Apple II having a full listing of
| the Monitor ROM, or the original IBM PC Technical Reference
| Manual.
| bombcar wrote:
| The very existence of those manuals improved the software,
| as the technical writers were trained in a different
| discipline than programming, and it really showed.
|
| Even some well-documented modern software is obviously
| documented by the programmers and programmer-adjacent.
| moregrist wrote:
| There are many things I feel nostalgic for in that era, but
| chunky manuals for specific software are at the bottom of
| that list.
|
| They weren't like textbooks, which have knowledge that tends
| to be relevant for decades. You'd get a new set with every
| software release, making the last 5-20 lbs of manuals
| obsolete.
|
| You did lose some of the readability of an actual book. Hard-
| copy manuals were better for that. But for most software
| manuals, I did more "look up how to do this thing" than
| reading straight through. And with a pdf on a CD you had much
| better search capabilities. Before that you'd have to rely on
| the ToC, the book index and your own notes. For many manuals,
| the index wasn't great. Full text search was a definite step
| up.
|
| Even the good ones, like the 1980s IBM 2-ring binder manuals,
| which had good indexes, were a pain to deal with and couldn't
| functionally match a PDF or text file on a CD for
| searchability.
| Nifty3929 wrote:
| I think another thing we lost was the sense of a software
| release being a complete, immutable product - and the
| development rigor required of that.
|
| You might expect now and again to get some optional
| updates/patches later, but that was rare - and rarer still
| for most people to even know about them.
|
| These days, software is never complete. Nothing is done. It's
| just a point-in-time state with a laundry list of bugs and
| TODOs that just roll out whenever. The software is just
| whatever git tag we're pointing to today.
|
| I understand how/why it has become like this - but it still
| makes me sad.
| russellbeattie wrote:
| > _" Software architect Grady Booch is the Chief Scientist for
| Software Engineering at IBM Research Almaden and a trustee of the
| Computer History Museum. He offers the following observations
| about the Photoshop source code."_
|
| OMG. Booch?? The father of UML is still around? Given that UML is
| a true crime against humanity, it just goes to show there is no
| justice in the world. (I want a lifespan refund for the amount of
| time I spent learning UML and Design Patterns back in the bad old
| Enterprise Java days. Oof)
| heap_perms wrote:
| I completed a CS degree just a year ago, and they absolutely
| wrecked us with UML. I'm still recovering mentally.
| goalieca wrote:
| UML used to be a staple of job interviews.
| forgetfulness wrote:
| It was going to be the future of Software Engineering in
| the 2000s, Software Architects laying out boxes for
| Software Bricklayers to implement as dictated, code
| generation tools were going to make programming trivial.
|
| For trivial CRUD apps, and maintaining modified versions of
| the generated code was a nightmare.
| pjmlp wrote:
| I was drawing UML before Christmas vacations, when one
| works at scale, drawing boxes to discuss implemenations
| works much better than throw away code.
|
| It is also a great way to document existing
| architectures.
| goalieca wrote:
| This AI hype cycle reminds me of that era.
| pjmlp wrote:
| On the contrary, UML is quite useful in enterprise
| architecture, and I am yet to find an alternative that isn't
| much worse.
|
| It is like the YAML junk that gets pushed nowadays in detriment
| of proper schemas, and validation tools we have in XML.
| ofrzeta wrote:
| Quite the praise by Grady Booch:
|
| "There are only a few comments in the version 1.0 source code,
| most of which are associated with assembly language snippets.
| That said, the lack of comments is simply not an issue. This code
| is so literate, so easy to read, that comments might even have
| gotten in the way."
|
| "This is the kind of code I aspire to write."
| crazygringo wrote:
| > _the lack of comments is simply not an issue_
|
| I'm looking at the code and just cannot agree. If I look at a
| command like "TRotateFloatCommand.DoIt" in URotate.p, it's 200
| lines long without a single comment. I look at a section like
| this and there's nothing literate about it. I have no idea what
| it's doing or why at a glance: pt.h := BSR
| (r.left + ORD4 (r.right), 1); pt.v := BSR (r.top + ORD4
| (r.bottom), 1); pt.h := pt.h - BSR (width, 1);
| pt.v := pt.v - BSR (height, 1); pt.h := Max (0,
| Min (pt.h, fDoc.fCols - width)); pt.v := Max (0, Min
| (pt.v, fDoc.fRows - height)); IF width >
| fDoc.fCols THEN pt.h := pt.h - BSR (width - fDoc.fCols
| - 1, 1); IF height > fDoc.fRows THEN pt.v
| := pt.v - BSR (height - fDoc.fRows - 1, 1);
|
| Just breaking up the function with comments delineating its
| four main sections and what they do would be a start. As would
| simple things like commenting e.g. what purpose 'pt' serves --
| the code block above is where it is first defined, but you
| can't guess what its purpose is until later when it's used to
| define something else.
|
| Good code does not make comments unnecessary or redundant or
| harmful. This is a myth that needs to die. Comments help you
| understand code much faster, understand the purpose of
| variables before they get used, understand the purpose of
| functions and parameters before reading the code that defines
| them, etc. They _vastly_ aid in comprehension. And those are
| just "what" comments I'm talking about -- the additional
| necessity of "why" comments (why the code uses x approach
| instead of seemingly more obvious approach y or z, which were
| tried and failed) is a whole other subject.
| tgtweak wrote:
| This actually looks surprisingly straightforward for what the
| function is doing - certainly if you have domain context of
| image editing or document placement. You'll find it in a lot
| of UI code - this one uses bit shifts for efficiency but what
| it's doing is pretty straightforward.
|
| For clarity and to demonstrate, this is basically what this
| function is doing, but in css:
|
| .container { position: relative;
|
| }
|
| .obj { position: absolute; left:
| 50%; top: 50%; transform:
| translate(-50%, -50%); }
| DoneWithAllThat wrote:
| Man I just don't know who to believe, you or the Chief
| Scientist for Software Engineering at IBM research Almaden.
| yearolinuxdsktp wrote:
| It's not a myth, it's a sound software engineering principle.
|
| Every comment is a line of code, and every line of code is a
| liability, and, worse, comments are a liability waiting to
| rot, to be missed in a refactor, and waiting to become a
| source of confusion. It's an excuse to name things poorly,
| because "good comment." The purpose of variables should be in
| their name, including units if it's a measurement. Parameters
| and return values should only be documented when not obvious
| from the name or type--for example, if you're returning
| something like a generic Pair, especially if left and right
| have the same type. We'd been living with decades of
| autocomplete, you don't need to make variables be short to
| type.
|
| The problem with AI-generated code is that the myth that good
| code is thoroughly commented code is so pervasive, that the
| default output mode for generated code is to comment every
| darn line it generates. After all, in software education,
| they don't deduct points for needless comments, and students
| think their code is now better w/ the comments, because they
| almost never teach writing good code. Usually you get kudos
| for extensive comments. And then you throw away your work.
| Computer science field is littered with math-formula-
| influenced space-saving one or two letter identifiers, barely
| with any recognizable semantic meaning.
| f1shy wrote:
| >> Every comment is a line of code, and every line of code
| is a liability, and, worse, comments are a liability
| waiting to rot,
|
| This is exactly my view. Comments, while can be helpful,
| can also interrupt the reading of the code. Also are not
| verified by the compiler; curious, in the era when everyone
| goes crazy for rust safety, there is nothing unsafer as
| comments, because are completely ignored.
|
| I do bot oppose to comments. But they should be used only
| when needed.
| crazygringo wrote:
| No. What you are describing is _exactly_ the myth that
| needs to die.
|
| > _comments are a liability waiting to rot, to be missed in
| a refactor, and waiting to become a source of confusion_
|
| This gets endlessly repeated, but it's just defending
| laziness. It's your _job_ to update comments as you update
| code. Indeed, they 're the _first thing_ you should update.
| If you 're letting comments "rot", then you're a bad
| programmer. Full stop. I hate to be harsh, but that's the
| reality. People who defend no comments are just saying, "I
| can't be bothered to make this code easier for others to
| understand and use". It's egotistical and selfish. The
| solution for confusing comments isn't no comments -- it's
| _good comments_. Do your job. Write code that others can
| read and maintain. And when you update code, start with the
| comments. It 's just professionalism, pure and simple.
| II2II wrote:
| For all we know, the comment came from someone who was
| doing their job (by your definition) and were bitten in
| the behind by colleagues who did not do their job. We do
| not live in an ideal world. Some people are sloppy
| because they don't know, don't care, or simply don't have
| the time to do it properly. One cannot put their full
| faith into comments because of that.
|
| (Please note: I'm not arguing against comments. I'm
| simply arguing that trusting comments is problematic. It
| is understandable _why_ some people would prefer to have
| clearly written code over clearly commented code.)
| jiggawatts wrote:
| > colleagues who did not do their job.
|
| That doesn't justify matching their sloth.
|
| Lead by example! Write comments half a page long or
| longer, _explaining_ things, not just expanding
| identifier names by adding spaces in between the words.
| bahmboo wrote:
| I appreciate your attempt to defend this position and I,
| and others, wish you good luck. In my many decades of
| working with humans writing code it simply has never
| happened.
| thayne wrote:
| No amount of good names will tell you _why_ something was
| done a certain way, or just as importantly why it _wasn 't_
| done a certain way.
|
| A name and signature is often not sufficient to describe
| what a function does, including any assumptions it makes
| about the inputs or guarantees it makes about the outputs.
|
| That isn't to say that it isn't necessary to have good
| names, but that isn't enough. You need good comments too.
|
| And if you say that all of that information should be in
| your names, you end up with very unwieldy names, that will
| bitrot even worse than comments, because instead of
| updating a single comment, you now have to update every
| usage of the variable or function.
| j16sdiz wrote:
| BSR = bitwise right-shift
|
| ORD4 = cast as 32bit integer.
|
| BSR(x,1) simply meant x divided by 2. This is very comment
| coding idom back in those days when Compiler don't do any
| optimization and bitwise-shift is much faster than division.
|
| The snippet in C would be: pt.h = (r.left +
| (int32_t)r.right) / 2; pt.v = (r.top +
| (int32_t)r.bottom) / 2; pt.h -= (width / 2);
| pt.v -= (height / 2); pt.h = max(0, min(pt.h,
| fDoc.fCols - width)); pt.v = max(0, min(pt.v,
| fDoc.fRows - height)); if (width > fDoc.fCols)
| { pt.h -= (width - fDoc.fCols - 1) / 2; }
| if (height > fDoc.fRows) { pt.v -= (height -
| fDoc.fRows - 1) / 2; }
| j16sdiz wrote:
| Reading the full function here https://github.com/amix/phot
| oshop/blob/2baca147594d01cf9d17d...
|
| If I understand it correctly, it was calculating the top-
| left point of the bounding box.
| exsf0859 wrote:
| That particular code is idiomatic to anyone who worked with
| 2D bitmap graphics in that era.
|
| pt == point, r == rect, h, v == horizontal, vertical,
| BSR(...,1) is a fast integer divide by 2, ORD4 promotes an
| expression to an unsigned 4 byte integer
|
| The algorithms are extremely common for 2D graphics
| programming. The first is to find the center of a 2D
| rectangle, the second offsets a point by half the size, the
| third clips a point to be in the range of a rectangle, and so
| on.
|
| Converting the idiomatic math into non-idiomatic words would
| not be an improvement in clarity in this case.
|
| (Mac Pascal didn't have macros or inline expressions, so
| inline expressions like this were the way to go for
| performance.)
|
| It's like using i,j,k for loop indexes, or x,y,z for graphics
| axis.
| DanHulton wrote:
| Xyz makes sense because that is what those axes are
| literally labeled, but ijk I will rail against until I die.
|
| There's no context in those names to help you understand
| them, you have to look at the code surrounding it. And even
| the most well-intentioned, small loops with obvious context
| right next to it can over time grow and add additional
| index counters until your obvious little index counter is
| utterly opaque without reading a dozen extra lines to
| understand it.
|
| (And i and j? Which look so similar at a glance? Never.
| Never!)
| kaibee wrote:
| ijk are standard in linear algebra for vector components.
|
| > (And i and j? Which look so similar at a glance? Never.
| Never!)
|
| This I agree with.
| eimrine wrote:
| What if not ijk? I know only uvw.
| jiggawatts wrote:
| Pretend to be a physicist and use m and n.
| zeckalpha wrote:
| i came from imaginary numbers which were extended to make
| quaternions.
| jonahx wrote:
| > but ijk I will rail against until I die.
|
| > There's no context in those names to help you
| understand them, you have to look at the code surrounding
| it.
|
| Hard disagree. Using "meaningful" index names is a
| distracting anti-pattern, for the vast majority of loops.
| The index is a meaningless structural reference -- the
| standard names allow the programmer to (correctly) gloss
| over it. To bring the point home, such loops could often
| (in theory, if not in practice, depending on the
| language) be rewritten as maps, where the index reference
| vanishes altogether.
| vilos1611 wrote:
| I respectfully disagree.
|
| The issue isn't the names themselves, it's the locality
| of information. In a 3-deep nested loop, i, j, k forces
| the reader to maintain a mental stack trace of the entire
| block. If I have to scroll up to the for clause to
| remember which dimension k refers to, the abstraction has
| failed.
|
| Meaningful names like row, col, cell transform structural
| boilerplate into self-documenting logic. ijk may be
| standard in math-heavy code, but in most production code
| bases, optimizing for a 'low-context' reader is not an
| anti-pattern.
| jonahx wrote:
| If the loop is so big it's scrollable, sure use row, col,
| etc.
|
| That was my "vast majority" qualifier.
|
| For most short or medium sized loops, though, renaming
| "i" to something "meaningful" can harm readability. And I
| don't buy the defensive programming argument that you
| should do it anyway because the loop "might grow bigger
| someday". If it does, you can consider updating the names
| then. It's not hard -- they're hyper local variables.
| vilos1611 wrote:
| In a single-level loop, i is just an offset. I agree that
| depending on the context (maybe even for the vast
| majority of for loops like you're suggesting) it's
| probably fine.
|
| But once you nest three deep (as in the example that
| kicked off this thread), you're defining a coordinate
| space. Even in a 10-line block, i, j, k forces the reader
| to manually map those letters back to their axes. If I
| see grid[j][i][k], is that a bug or a deliberate
| transposition? I shouldn't have to look at the for clause
| to find out.
| ori_b wrote:
| If you see grid[y][z][x], is it a bug or a deliberate
| transposition?
| crazygringo wrote:
| > _Converting the idiomatic math into non-idiomatic words
| would not be an improvement in clarity in this case._
|
| You seem to be missing my point. It's not about improving
| "clarity" about the math each line is doing -- that's
| precisely the kind of misconception so many people have
| about comments.
|
| It's about, how _long_ does it take me to understand the
| _purpose_ of a block of code? If there was a simple comment
| at the top that said [1]: # Calculate top-
| left point of the bounding box
|
| then it would actually be helpful. You'd understand the
| _purpose_ , and understand it _immediately_. You wouldn 't
| have to decode the code -- you'd just read the brief remark
| and move on. That's what literate programming is about, in
| spirit -- writing code to be easily _read_ at levels of the
| hierarchy. And very specifically _not_ having to read
| _every single line_ to figure out what it 's doing.
|
| The original assertion that "This code is so literate, so
| easy to read" is demonstrably false. Naming something "pt"
| is the _antithesis_ of literature programming. And if you
| insist on no comments, you 'd _at least_ need to name is
| something like "bbox_top_left". A generic variable name
| like "pt", that isn't even introduced in the context of a
| loop or anything, is a cardinal sin here.
|
| [1] https://news.ycombinator.com/item?id=46366341
| jefftk wrote:
| It all depends on how much context the reader has. For
| some audiences a comment explaining bounding boxes would
| be helpful; for others your example comment adds nothing
| that isn't immediately apparent from the code.
|
| Part of figuring out a reasonable level of commenting
| (and even variable naming) is a solid understanding of
| your audience. When in doubt aiming low is good practice,
| but keep in mind that this was 2D graphics software
| written at a 2D graphics software company.
| meesles wrote:
| I think at certain calibers of work, like graphics
| programming in lower level languages, the best you can do
| is be readable and clear to others who are experts in
| your field. In other words, you aren't the target
| audience. There is likely no way to write this specific
| kind of code in a way that satisfies all audiences. I'm
| willing to concede then that the 'best' way to write this
| type of code is determined by the ones writing it, not us
| with standard views on software.
| echelon wrote:
| A graphics programmer does not need that.
|
| To help understand, you need to see this code as math.
| Graphics programming algorithms are literally math.
|
| You're asking for training wheels comments, which just
| get in the way for those who are familiar with the
| domain.
|
| I'm sure a few graphics programming engineers might want
| calls to react useState(), useEffect(), etc. to be
| documented in a codebase, yet a react programmer would
| scoff at the idea.
| pixelesque wrote:
| As other comments have mentioned, context does matter, and as
| someone with a lot of 2D image/pixel processing experience,
| other than the 'BSR' and 'ORD4' items - which are clearly
| common in the codebase and in that era of computing, all that
| code makes perfect sense.
|
| Also, breaking things down to more atomic functions wasn't
| the best idea for performance-sensitive things in those days,
| as compilers were not as good about knowing when to inline
| and not: compiler capabilities are a lot better today than
| they were 35 years ago...
| georgemcbay wrote:
| The code's functionality is immediately obvious to me as
| someone who works a lot with graphics coordinate systems.
|
| I'm sure the code would be immediately obvious to anyone who
| would be working on it at the time.
|
| Comments aren't unnecessary, they can be very helpful, but
| they also come with a high maintenance cost that should be
| considered when using them. They are a long-term maintenance
| liability because by design the compiler ignores them so its
| very easy to change/refactor code and miss changing a comment
| and then having the comment be misleading or just plain
| wrong.
|
| These days one could make some sort of case (though I
| wouldn't entirely buy it, yet) that an LLM-based linter could
| be used to make sure comments do not get disconnected from
| the code they are documenting, but in 1990? not so much.
|
| Would I have used longer variable names for slightly more
| clarity? Today, sure. In 1990, probably not. Temporal context
| is important and compilers/editors/etc have come a long way
| since then.
| coldtea wrote:
| Are you familiar with the domain?
|
| Because it's quite clear, everything is well named, and the
| filename also gives the context.
| ozfive wrote:
| Finds the center of a rectangle r Positions a width x height
| region centered on that rectangle.
|
| Clamps the result so it doesn't go outside the document.
|
| If the region is bigger than the document, it re-centers
| instead of snapping to (0,0).
| snvzz wrote:
| >To download the code you must agree to the terms of the license,
| which permits only non-commercial use and does not give you the
| right to license it to third parties by posting copies elsewhere
| on the web.
|
| Note this is a toxic license. Accepting it and/or reading of the
| code has potential for legal liability.
|
| Still, applaud releasing the source code, even if encumbered.
| Preservation is most important, and any legal teeth will
| eventually expire with the copyright.
| kmoser wrote:
| > Note this is a toxic license. Accepting it and/or reading of
| the code has potential for legal liability.
|
| How would this potentially expose you to legal liability?
| cramcgrab wrote:
| Wow! Writing photoshop while a phd student at Michigan! Wish
| current students would do some code
| system2 wrote:
| They are good at dancing for TikTok videos, though.
| incanus77 wrote:
| I ran an exhibit of eight machines from my retrocomputing
| collection last year, including a 1986 Mac Plus with 1MB RAM
| running Photoshop 1.0. People really enjoyed it! It's kind of
| remarkable what you can still do with it and how freeing it is to
| have singular focus in an app.
| steve1977 wrote:
| "His brother John, working at the movie visual effects company
| Industrial Light & Magic" is underselling John Knoll a bit - he
| became one of the more prominent figures there and won two Oscars
| for his work (and was nominated for more).
|
| Taking his contribution for Photoshop into account, one could say
| that if you saw mainstream motion or still pictures in the
| Western world in the last three decades, you'll probably saw
| something influenced by him in one way or another.
| jamesnorden wrote:
| Still better than GIMP... /s (maybe)
| swammie wrote:
| I learned Photoshop while working with John at ILM in the 90's.
| Cool!
___________________________________________________________________
(page generated 2025-12-23 23:00 UTC)