00:09:06
##forth
<vms14>
cleobuline you have to make the bot not send large messages though
00:09:25
##forth
<vms14>
you can make it use a pastebin service or just cut the output
00:10:53
##forth
<cleobuline>
i can suppress the word "WORDS"
00:11:09
##forth
<cleobuline>
and suppress the word "SEE"
00:11:53
##forth
<vms14>
no, don't be lazy
00:11:59
##forth
<vms14>
both words are useful
00:12:05
##forth
<cleobuline>
or y can set a VARIABLE SILENCE
00:12:25
##forth
<vms14>
you can for example make the bot answer in private
00:12:29
##forth
<cleobuline>
set to 1 it will only print the stack
00:12:39
##forth
<vms14>
and flood the user with private messages
00:14:00
##forth
<cleobuline>
tomorrow i will do a MUTE variable to stop all the message , just print the stack
00:15:55
##forth
<cleobuline>
ForthBot: CAT
00:15:55
##forth
<ForthBot>
/_/
00:18:48
##forth
<cleobuline>
too late it's midnigh for me
00:19:54
##forth
<cleobuline>
next action is going to bed
00:19:59
##forth
<vms14>
that solution is not cool
00:20:07
##forth
<cleobuline>
why ?
00:20:23
##forth
<vms14>
because you will make my new defined word useless :/
00:20:30
##forth
<vms14>
ForthBot: :D
00:20:30
##forth
<ForthBot>
:D
00:21:08
##forth
<vms14>
just cut the output to a limit of characters
00:21:10
##forth
<cleobuline>
lol no it will stille act for ." and buffer CR
00:21:16
##forth
<vms14>
if you want an easy solution
00:22:15
##forth
<cleobuline>
This robot is not very talkative
00:26:15
##forth
<cleobuline>
do you try some recursion you must redefine : :D ." ForthBot: :D '
00:26:26
##forth
<cleobuline>
do you try some recursion you must redefine : :D ." ForthBot: :D ' ;
00:26:43
##forth
<cleobuline>
you ca get an infinite loop
00:27:51
##forth
<cleobuline>
try ForthBot :D ." ForthBot: :D ' CR ; D:
00:28:12
##forth
<cleobuline>
you do ? vms14
00:28:46
##forth
<cleobuline>
me not ...
00:29:47
##forth
<cleobuline>
better not to try i think
00:31:43
##forth
<cleobuline>
better vms14 :D 1 ." ForthBot: :D" CR ; D: , it will stop with a stack overflow
00:34:39
##forth
<cleobuline>
go to bed
00:51:43
##forth
<cleobuline>
!gforth : :D ." ForthBot: :D ' CR ; D:
00:51:43
##forth
<gforth_eval_bot>
Gforth 0.7.3, Copyright (C) 1995-2008 Free Software Foundation, Inc.
00:52:36
##forth
<cleobuline>
!gforth : :D ." ForthBot: :D " CR ; D:
00:53:45
##forth
<cleobuline>
!gforth : test ." ForthBot: test" CR ; test
00:53:46
##forth
<gforth_eval_bot>
ForthBot: test
00:54:01
##forth
<cleobuline>
!gforth : :D ." gforth: :D " CR ; D:
00:54:54
##forth
<cleobuline>
!gforth : test ." !gforth: test" CR ; test
00:54:55
##forth
<gforth_eval_bot>
!gforth: test
00:55:35
##forth
<cleobuline>
!gforth : test ."!gforth: test" CR ; test
00:55:51
##forth
<cleobuline>
mmm
00:56:20
##forth
<cleobuline>
does not work !gforth : test ." !gforth: test" CR ; test
00:57:34
##forth
<cleobuline>
I am disappointed
00:58:02
##forth
<cleobuline>
!gforth : test ." !gforth: test" ; test
00:58:03
##forth
<gforth_eval_bot>
!gforth: test
01:01:32
##forth
<vms14>
!gforth ." ForthBot: :D"
01:01:44
##forth
<vms14>
:/
01:02:01
##forth
<cleobuline>
il est parti vms14
01:03:07
##forth
<cleobuline>
ForthBot: LOAD "test.fth"
01:03:19
##forth
<cleobuline>
!gforth ." ForthBot: :D"
01:03:52
##forth
<cleobuline>
!gforth ." ForthBot: :D" CR
01:04:14
##forth
<cleobuline>
!gforth ." hello world "
01:04:35
##forth
<cleobuline>
it does not print gforth
01:05:24
##forth
<cleobuline>
I am disappointed vms14
01:05:42
##forth
<cleobuline>
ForthBot: :D
01:05:42
##forth
<ForthBot>
:D
01:08:09
##forth
<cleobuline>
what's the fuck ?
02:18:50
##forth
<vms14>
guys I have an existential question with variables in my toy rpn lang
02:19:10
##forth
<vms14>
I have 4 words to work with variables: var variable set-var and get-var
02:19:48
##forth
<vms14>
var and variable create the variable and also create a word with the same name that will push that variable on the stack, so you do not really need to use get-var
02:21:06
##forth
<vms14>
but since I have some sort of compiling thingy, if I create a child definition that wants to use that created word instead of get-var, this word needs to exist at compile time, this is why variable is an immediate word
02:21:40
##forth
<vms14>
variable reads a word from the source code and creates the variable and the word that will push it on the stack
02:22:02
##forth
<vms14>
var is not immediate and gets the name and the value from the stack at runtime
02:22:54
##forth
<vms14>
: oh variable some-var 'some-var 24 set-var : meh some-var ; meh ;
02:23:23
##forth
<vms14>
since variable is immediate it will create a word named 'some-var' that 'meh' will be able to find at compile time
02:23:49
##forth
<vms14>
if I instead do. : oh 'some-var 24 var : meh some-var ; meh ;
02:24:31
##forth
<vms14>
meh will not find 'some-var' because var is not immediate and could not create the word yet, so in meh I have to use 'some-var get-var instead
02:25:09
##forth
<vms14>
it's kind of confusing and I do not know how to avoid having to use get-var for every variable without adding the immediate version
02:25:34
##forth
<vms14>
set-var will only update an existing variable at runtime and trigger an error if it's not found
02:28:38
##forth
<vms14>
seems that is better to get rid of the immediate word 'variable' and use always get-var, not having the shortcut word being defined, but I would like to avoid having to use 'some-var get-var and instead just say: some-var
02:45:36
##forth
<vms14>
I guess I will just rename 'variable' to 'declare'
04:56:28
##forth
<KipIngram>
There seems to be some dissatisfaction with how Forth already handles VARIABLE that I think must come from being steeped in more traditional languages before approaching Forth.
04:57:26
##forth
<KipIngram>
The idea that executing a variable deposites that variable's address on the stack, and that I need to do @ if I want the value on the stack, just seems entirely fine to me - I just have no desire to introduce a ton of complexity into things to change that.
04:58:17
##forth
<KipIngram>
I think for most programmers the first time they're ever exposed to dealing with an item's address is when they hit the C & operator.
05:05:55
##forth
<Shark8>
KipIngram, Honestly, it sounds kind of similar to BLISS.
05:06:43
##forth
<Shark8>
(In BLISS every variable is an address and the contents are denoted with a dot so X is the address, X. is the thing that X refrences.)
05:21:54
##forth
<KipIngram>
Yes, like C pointers with slightly different syntax. I think assembly helps counteract it - ultimately EVERY variable / data structure is "somewhere in RAM," and you use the address of that place to get at the content.
05:22:11
##forth
<KipIngram>
It's very tightly connected to the way computers actually work.
09:39:56
##forth
<veltas>
Words like ON and OFF are made possible by VARIABLE , so you can use RPN to describe operations on a variable, which is more forthy
09:40:11
##forth
<veltas>
So you can say CLUTCH ON or WARNINGS OFF as I do for gforth
09:41:04
##forth
<veltas>
It makes the most sense to refer to the variable as its address, because that's the *variable*, the content at that address is the value inside the variable
09:41:57
##forth
<veltas>
And I can do equality check on addresses to decide if it's the same *variable* in question, which is different to checking if they're different variables with the same *value*
09:42:38
##forth
<veltas>
The fact that *sometimes* you want the address, to me, means that you *always* want VARIABLE , if you have to choose either VARIABLE or VALUE
11:06:31
##forth
<KipIngram>
100% agree.
11:57:33
##forth
<xentrac>
KipIngram: my concern is just that it's verbose, and in the Forth context, that makes it bug-prone.
11:57:56
##forth
<xentrac>
just as it was in BLISS
12:00:00
##forth
<xentrac>
because IME passing the memory address of a variable to something other than @ is far less common than just reading the variable
12:00:45
##forth
<xentrac>
although there's no you could
12:01:42
##forth
<veltas>
Although bear in mind having to write @ after variable name is one of the less verbose Forth syntaxes
12:02:04
##forth
<xentrac>
although there's no Standard way to do it, and it runs into the usual annoyances with state, you could replace on and off with words that work with values: enable clutch disable warnings
12:02:43
##forth
<xentrac>
generally I find Forth to be rather terse?
12:03:18
##forth
<veltas>
It's not terse at all, at many things
12:03:28
##forth
<veltas>
It really depends, it is good at some point-free stuff
12:04:29
##forth
<veltas>
I mean best case : SQUARE DUP * ; vs worst case we saw recursive factorial earlier, much nicer in most languages e.g. haskell and C
12:05:03
##forth
<xentrac>
I find the state dependency of char [char] ' ['] etc. to be progressively more annoying
12:05:13
##forth
<KipIngram>
You pass addresses around quite a lot when manipulating data structures like linked lists, doubly linked lists, and so on.
12:05:40
##forth
<xentrac>
I wonder if the cmForth approach of different vocabularies for compilation and interpretation makes that better or worse
12:05:53
##forth
<xentrac>
KipIngram: yes, but not addresses of variables
12:06:20
##forth
<xentrac>
those mostly only get passed to ! @ +! 1+! on off
12:06:36
##forth
<KipIngram>
I hardly ever use variables anyway. I just think that like anything you do, it becomes second nature. The @ is just part of the idiom.
12:07:03
##forth
<KipIngram>
But I'll still stick with my strongest argument - the computer works through addresses, and for me Forth is all about putting you close to the computer.
12:07:32
##forth
<xentrac>
It's possible; people make the same claim about RPN, and I still find it less readable than pop infix
12:07:43
##forth
<KipIngram>
Abstraction is counter to the whole Forth philosophy in my opinion. At least at the foundation level - you abstract when creating applications, as suits the application.
12:08:10
##forth
<xentrac>
I thought Forth was all about building a problem-oriented language
12:08:30
##forth
<KipIngram>
I think that's just a matter of familiarity - starting in my freshman year at college I've used RPN calculators, and that's just how my brain works now.
12:08:32
##forth
<veltas>
According to Chuck and nobody else
12:08:33
##forth
<xentrac>
(As parsimoniously as possible)
12:09:15
##forth
<xentrac>
yeah, I've been using RPN since probably 01983, but maybe less often than you have
12:09:32
##forth
<xentrac>
I think it has big advantages as a UI paradigm
12:09:51
##forth
<KipIngram>
It's about using your machinery to solve problems, yes. Look, I'm a hardware guy. I live on the hardware end of the spectrum, and I like how Forth "fits" that. If you're on the other end of the spectrum it's totally reasonable for you to feel differently.
12:10:52
##forth
<KipIngram>
I value Forth for the way it lets me manipulate the resources of my hardware.
12:11:02
##forth
<KipIngram>
I guess some folks WANT the hardware hidden, but I don't.
12:11:29
##forth
<veltas>
You've probably got more experience than me xentrac, but regardless I have seen this conversation a number of times in here
12:11:39
##forth
<xentrac>
yeah, I'm definitely not arguing for *hiding* the hardware
12:11:43
##forth
<veltas>
And have benefit of benefitting from standing on these giants shoulders
12:12:03
##forth
<xentrac>
veltas: oh, I wouldn't be sure I have more experience
12:12:14
##forth
<
xentrac>
I wrote about my perspective on language design 25 years ago at https://paulgraham.com/redund.html but I should rethink it in the light of experience
12:12:27
##forth
<veltas>
And I know that myself and basically all the serious Forthers in here seem to have not found Chuck's problem-oriented-language description to be that valid in practice
12:12:39
##forth
<KipIngram>
The other great thing about Forth, though, is that you can do what you want with it. If you want VALUE, you can create it.
12:12:45
##forth
<KipIngram>
It's all good.
12:13:12
##forth
<veltas>
I think your experience with Forth in 80's is probably more valuable than my experience which starts in the last decade
12:13:14
##forth
<xentrac>
Paul was arguing for Lisp on the basis of something like Chuck's POL point of view
12:13:17
##forth
<veltas>
Even if I have more time with it
12:13:33
##forth
<xentrac>
oh, I don't have any experience with Forth in the 80s, just HP calculators
12:13:44
##forth
<veltas>
Because I don't think Forth has much value left at this point, in the 80's it was more valuable
12:14:09
##forth
<xentrac>
I learned of the existence of Forth in 01994 from books the library was throwing out
12:14:42
##forth
<veltas>
Fair enough
12:14:51
##forth
<veltas>
I like old tech books that get thrown uout
12:14:51
##forth
<xentrac>
though I had previously written an address book program in HP 48GX RPL
12:15:02
##forth
<veltas>
I used to have a lot of them, I've thrown them out myself though now
12:15:07
##forth
<veltas>
Old DOS books etc
12:15:17
##forth
<xentrac>
but RPL isn't Forth: garbage-collected, etc.
12:15:18
##forth
<KipIngram>
I ran across it in 1983 or so, and was immediately interested because of my calculator usage. It was a while before I appreciated it for more than just being RPN.
12:15:37
##forth
<xentrac>
I don't remember if RPL has macros
12:16:28
##forth
<xentrac>
(immediate words)
12:18:11
##forth
<xentrac>
To recap another old discussion, I'm pretty sure Forth has been strongly influenced over the last 30 years by two big demographic shifts:
12:19:28
##forth
<xentrac>
- away from people who are looking for ways to "make hard things easy" and toward people who are looking for ways to "make easy things hard", though of course valuing puzzle-solving was a part of Forth culture since Mohasco
12:19:56
##forth
<xentrac>
- an increasing tendency to asceticism
12:20:24
##forth
<xentrac>
I wouldn't claim that either of those is the reason my preferences differ from KipIngram's, for example
12:20:39
##forth
<veltas>
Yeah I agree and I think it's quite awkward when the two groups end up trying to work together
12:21:09
##forth
<xentrac>
but I think they've influenced the context in which we're having the discussion
12:21:19
##forth
<veltas>
They often end up at odds
12:21:27
##forth
<xentrac>
unsurprisingly :-)
12:21:51
##forth
<veltas>
Partly though this is because Forth for 99.9% of jobs is making easy things hard
12:22:09
##forth
<veltas>
So you can't blame the latter camp from bulldozing any conversation about trying to keep stuff simple/easy
12:23:10
##forth
<xentrac>
I wanted to understand diode logic better
12:23:23
##forth
<xentrac>
so I made a BCD-to-7-segment decoder
12:24:04
##forth
<xentrac>
well! I simulated it!
12:24:42
##forth
<xentrac>
that surely qualifies as "making easy things hard"
12:26:07
##forth
<xentrac>
I think it would be fun to build this circuit using LEDs for the diode logic and maybe a bit more current
12:30:53
##forth
<xentrac>
but I haven't actually *made* it yet. Maybe it would be a little less cliché to do an excess-3 decoder or something
14:31:14
##forth
<cleobuline>
ForthBot: LOAD "test.fth"
14:31:14
##forth
<cleobuline>
ForthBot: CAT
14:38:47
##forth
<cleobuline>
may be truncated
14:39:06
##forth
<xentrac>
KipIngram: wow!
14:39:11
##forth
<KipIngram>
It is, yes.
14:39:14
##forth
<KipIngram>
25740557956866022603190417032406235170085879617892222278962
14:39:17
##forth
<KipIngram>
3703897374720000000000000000000000000000000000000000000000000
14:39:19
##forth
<xentrac>
I petted two kittens this morning at the greengrocer's
14:39:27
##forth
<KipIngram>
That's what's added in the Python version.
14:39:33
##forth
<KipIngram>
:-)
14:39:49
##forth
<KipIngram>
Then we got the second one so he'd have a companion.
14:40:04
##forth
<xentrac>
ForthBot: 10 FACT .
14:40:05
##forth
<ForthBot>
3628800
14:40:14
##forth
<xentrac>
ForthBot: 16 FACT 6 FACT / .
14:40:14
##forth
<ForthBot>
29059430400
14:40:15
##forth
<KipIngram>
Gorgeous black and white calico.
14:40:51
##forth
<xentrac>
I'd back-of-envelope estimated that to be about 10¹⁰, I was low by a factor of 2.9
14:41:53
##forth
<xentrac>
forgot my cellphone when I went out to go food shopping, got caught in a thunderstorm, sought refuge in a gas station (virtually all gas stations here serve Italian cappuccino and have tables and chairs)
14:42:29
##forth
<KipIngram>
Good gas stations.
14:42:40
##forth
<xentrac>
No soap or toilet paper in the bathrooms, though.
14:43:09
##forth
<xentrac>
and I got to wondering about the number of distinct 4-bit codes for decimal, such as BCD and excess-3
14:44:20
##forth
<xentrac>
so I estimated 16!/6! as √(16·7)¹⁰
14:45:55
##forth
<KipIngram>
Interesting. cleobuline, log2 of your 200! result above is 846 and change. It's not immediately obvious to me why it would truncate theree.
14:46:22
##forth
<KipIngram>
It's not an even multiple of 64 or anything like that.
14:46:41
##forth
<KipIngram>
I'm betting it's a glitch in your bignum stuff, maybe?
14:47:55
##forth
<KipIngram>
Or maybe just your output - you couldn't have gotten all those high order digits right unless the calculation was done properly.
14:48:06
##forth
<xentrac>
KipIngram: maybe IRC
14:48:46
##forth
<KipIngram>
Oh, that could be too.
14:49:06
##forth
<KipIngram>
The Python is right (not that I really doubted it) - I calculated it manually and got the same result.
14:49:32
##forth
<cleobuline>
LOAD "test.fth"
14:49:43
##forth
<cleobuline>
ForthBot: LOAD "test.fth"
14:49:56
##forth
<KipIngram>
It makes sense that it would have a bunch of zeros at the end; every multiple of 10 or 100 is going to contribute one.
14:50:52
##forth
<cleobuline>
ForthBot: 200 FACT
14:50:52
##forth
<cleobuline>
ForthBot: .
14:51:05
##forth
<KipIngram>
Actually I guess the multiples of 100 contribute two.
14:51:17
##forth
<cleobuline>
yes
14:51:27
##forth
<KipIngram>
So that's 24 zeroes without even finding the non-obvious ones.
14:51:38
##forth
<[bot]konilo>
konilo bot ready; send code with a !konilo prefix. Sessions expire after 30 minutes of inactivity; an output link will be provided. Refresh to see updates.
14:54:31
##forth
<cleobuline>
ForthBot: 200 FACT 1 - .
14:54:31
##forth
<ForthBot>
788657867364790503552363213932185062295135977687173263294742533244359449963403342920304284011984623904177212138919638830257642790242637105061926624952829931113462857270763317237396988943922445621451664240254033291864131227428294853277524242407573903240321257405579568660226031904170324062351700858796178922222789623703897374719999999999999999999999999999999999999999999999999
15:49:53
##forth
<cleobuline>
ForthBot: STRING TEST " ceci est un test ! " TEST ! TEST @ PRINT
15:49:53
##forth
<ForthBot>
ceci est un test !
15:50:51
##forth
<cleobuline>
more consistant
15:51:56
##forth
<crc>
!konilo hello
15:51:56
##forth
<[bot]konilo>
crc: Hello! You can now start sending code with !konilo <code>. Use !konilo goodbye to end your session.
15:51:56
##forth
<[bot]konilo>
Shutting down...
15:52:46
##forth
<crc>
cleobuline: the equivalent would be :cube dup dup n:mul n:mul n:put ; cube
15:53:23
##forth
<cleobuline>
ha ... a new protocol yet !
15:53:25
##forth
<crc>
(my systems are not standard forth models)
15:57:11
##forth
<xentrac>
crc: 30 seconds is probably orders of magnitude too short
15:57:34
##forth
<crc>
?
15:58:24
##forth
<xentrac>
KipIngram: and naturally it's 5-limited rather than 2-limited
15:59:03
##forth
<xentrac>
crc: [bot]konilo said sessions time out after 30 seconds
15:59:49
##forth
<crc>
Should be 30 minutes
16:00:40
##forth
<xentrac>
that sounds reasonable
16:03:22
##forth
<crc>
It'll be better than that when done; I can have the vm save the full state when idle and restore it on demand
16:06:32
##forth
<vms14>
so every user will have it's own persistent session? :0
16:06:34
##forth
<KipIngram>
Sure - there are plenty of evens to handle the fives.
16:06:56
##forth
<KipIngram>
Sorry to get fixated on that - I just wanted to see it work out.
16:07:01
##forth
<crc>
vms14: yes
16:07:07
##forth
<vms14>
that's cool
16:07:19
##forth
<vms14>
now we just have to learn retro forth
16:08:04
##forth
<crc>
This is konilo, which is not quite the same as retroforth
16:08:06
##forth
<cleobuline>
ForthBot: zozo STRING " ceci est un test " zozo ! zozo @ PRINT
16:08:06
##forth
<ForthBot>
Unknown word: zozo
16:08:07
##forth
<ForthBot>
Missing closing quote
16:08:34
##forth
<vms14>
ForthBot: :D
16:08:34
##forth
<ForthBot>
Unknown word: :D
16:08:37
##forth
<vms14>
:/
16:08:48
##forth
<cleobuline>
LOAD "test.fth"
16:08:54
##forth
<cleobuline>
ForthBot: :D
16:08:55
##forth
<ForthBot>
Unknown word: :D
16:09:00
##forth
<vms14>
xd
16:09:24
##forth
<cleobuline>
ForthBot: : :D ." :D" ;
16:09:52
##forth
<vms14>
crc where is the documentation?
16:09:57
##forth
<crc>
(major differences are strings being arrays instead of null terninated, removal of word classes, simpler sigil model, a different dictionary structure, and being a more constrained, block oriented system)
16:10:52
##forth
<crc>
vms14: konilo.org
16:10:52
##forth
<cleobuline>
ForthBot: zozo " ceci est un test " S!
16:11:55
##forth
<KipIngram>
xentrac: Looks like 200! has 2^197 in its factorization.
16:13:16
##forth
<vms14>
so I can make my own namespace
16:13:23
##forth
<xentrac>
cleobuline: you might want to limit ForthBot to one response line per trigger?
16:13:35
##forth
<vms14>
can it be more than one char?
16:13:42
##forth
<KipIngram>
2^197*3^97*5^49*7^32+11^19*13^16+...
16:13:52
##forth
<KipIngram>
* at the end, rather.
16:13:54
##forth
<xentrac>
KipIngram: that makes sense
16:14:21
##forth
<vms14>
oh they are like reader chars
16:14:29
##forth
<KipIngram>
In general it's 200//N*200//(N^2)*... so long as N^M is less than 200.
16:14:35
##forth
<KipIngram>
Ugh.
16:14:37
##forth
<KipIngram>
+
16:14:47
##forth
<KipIngram>
200//N + 200//(N^2) + ...
16:15:06
##forth
<xentrac>
I mean 64! includes 32 multiples of 2, 16 of which are multiples of 4, 8 of which are multiples of 8, 4 of which are multiples of 16, 2 of which are multiples of 32, and one of which is a multiple of 64 (64 itself)
16:15:16
##forth
<xentrac>
which works out to 63 2s
16:15:43
##forth
<vms14>
I have a similar if xd
16:15:47
##forth
<KipIngram>
Right right. Which seems to be telling us that factorials are particularly easy to factor.
16:15:54
##forth
<xentrac>
so you'd think that usually N! would have a factor of 2ⁿ where n is almost N
16:15:58
##forth
<vms14>
1 ("is one" print) if
16:16:07
##forth
<vms14>
but it also accepts lambdas or the name of a word
16:16:10
##forth
<KipIngram>
Yes, excellent point.
16:17:13
##forth
<KipIngram>
Numbers are fun.
16:17:20
##forth
<vms14>
I have : for compiling words and :: for words that are interpreted instead of compiled
16:17:55
##forth
<vms14>
{ } compiles the code and pushes a lambda on the stack, [ ] does the same but without compiling
16:18:25
##forth
<vms14>
crc do you have some code to show of something you have done with retro forth or konilo?
16:18:39
##forth
<vms14>
I'm curious on how you can manage complexity with it
16:18:46
##forth
<crc>
vms14: sigils are limited to single characters
16:18:53
##forth
<vms14>
or whether you have written a large codebase
16:21:49
##forth
<crc>
my major projects are not, in general, large pieces of code, but do involve many smaller pieces (e.g., the order management system I wrote for my employer has ~100 small modules, tied together to generate browser-based & terminal front ends, and a separate set of modules to interface with the local label printers)
16:22:56
##forth
* crc has a sizeable amount of code not published publicly, for various reasons
16:23:13
##forth
<veltas>
Avoided backlash so far from your employer for using an unconventional solution?
16:23:42
##forth
<crc>
no backlash there; I have free reign to choose the tools I use for the programming I do for them :)
16:24:12
##forth
<xentrac>
:)
16:27:15
##forth
<veltas>
How much involvement do they have in the software lifecycle?
16:32:16
##forth
<crc>
very little. I take in suggestions & requests, but all development is done at my discretion & when I see fit to schedule time for programming
16:35:12
##forth
<crc>
(po
16:36:41
##forth
<crc>
programming isn't my primary role at work; I mostly work in sales, do some purchasing, training, and fill various other roles as needed
16:45:11
##forth
<xentrac>
makes sense that other people at the company wouldn't argue with you about how to write softwar then
16:47:58
##forth
<KipIngram>
The programming I've done at work has been mostly solo too, which I much prefer over having to integrate with a team and conform to their standards.
17:36:49
##forth
<user51>
KipIngram: Forth programmers in a nutshell :)
17:38:57
##forth
<user51>
Not making any judgement, I think both ways have their merits.. on your own it's very easy and fun to experiment, but with a group you also get network effects, and if you get a good team.. that's on the same page as critical mass.
18:47:32
##forth
<xentrac>
two people can find each other's bugs more easily than their own
18:50:52
##forth
<vms14>
and have flame wars about editors and brace styles
18:54:16
##forth
<KipIngram>
xentrac: Yeah, that sounds right. The two things share a mind set, I guess.
18:55:43
##forth
<xentrac>
or they can learn to use each other's editors
18:55:47
##forth
<xentrac>
that's how we did it in the past
20:28:05
##forth
<
[bot]konilo>
[bot]konilo is here! Send '!konilo hello' to start a konilo session. This is *not* a standard Forth model. See http://konilo.org for more information. (Note: currently experimental, and not yet persistent across relaunches of the bot)
20:33:31
##forth
<crc>
it's working somewhat better now. Some of the output gets lost though; working on fixing that, preventing flooding, and then will finish the session stuff for separate blocks for each user