Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
eli_oat has quit [Quit: WeeChat 2.8]
sts-q has quit [Ping timeout: 252 seconds]
<KipIngram>
Heh. This LISP stuff - I see a pattern. Need to do something new? Just wrap another layer of (...) around what you already have.
<KipIngram>
What prompted me to say that is label notation.
sts-q has joined #forth
gravicappa has joined #forth
mtsd has joined #forth
<proteusguy>
KipIngram, we were the first agile dev shop in SEAsia as far as I can tell. The techniques and mindset are absolutely powerful tools - but this abandonment of "architecture" is certainly nonsense. Comes mostly from the early XP crowd and people shilling the magic sugar water - mostly consultants who don't have project deliverable responsibilities.
<proteusguy>
I
<proteusguy>
I'm a fan of fixed length iterations, story cards, story points for estimating via planning poker, & TDD. But I also believe strongly in architecture. Main thing is to delay decisions as long as you can, push the hard stuff up front, always focus on delivering value and not over engineering.
joe9 has quit [Ping timeout: 240 seconds]
joe9 has joined #forth
neuro_sys has joined #forth
<neuro_sys>
I'm messing around with create...does>, I wonder if it's possible to mark does> part as immediate.
<mstevens>
I used to be a huge TDD addict but I've realised the error of my ways, you can't just TDD harder and hope complicated algorithms magically emerge.
jedb has quit [Ping timeout: 240 seconds]
<neuro_sys>
TDD isn't the phase where algorithms are designed though. It's only meant for the implementation phase and to reduce bugs from small mistakes when typing in the code. Then again I don't necessarily do TDD for work in the sense of "first write tests, then the implementation". At any rate, I do test the public interface for all branches.
<neuro_sys>
Ah and the biggest benefit is not when you write the code, but when later you change something, thus noticing if there was a regression.
<mstevens>
neuro_sys: My wrong belief was you didn't have to write algorithms anymore, you just TDD'd and hoped they magically appeared.
<neuro_sys>
I see.
<neuro_sys>
My mindset at work at least is to believe/assume that if the code submitted has no tests, then there's no proof that it works correctly.
<mstevens>
I eventually realised the error of my ways. I still think writing lots of tests is good, though.
<neuro_sys>
It's very costly overall, but really helps with the quality in the long run.
<neuro_sys>
But for hobby projects, who has time to write tests :P
<boru>
I think the effectiveness of any of these methodologies depends on what you're trying to do. For example, in a number of deeply embedded jobs in regulated industries over the last decade or so, they've tried to shove in things like agile. This simply does not work for electronics, FPGAs, firmware etc. I think the same goes for TDD. You can accommodate coarse test plans in the requirements phase of most
<boru>
projects. Typically, this happens when you have broken down high level requirements to technical requirements and you want to be able to prove that each one was met.
<boru>
Last few decades, rather.
jedb has joined #forth
<boru>
Testing is good, but engineers are primarily not test engineers. In the same way they say a programmer shouldn't test their own code, I posit they shouldn't design their own tests, either. It's less about meeting actual requirements then than mostly meaningless metrics like test coverage.
<mstevens>
Agile comes from a particular environment and I think makes most sense in that environment.
<boru>
Agreed.
<neuro_sys>
I agree that ideally the programmer shouldn't test their own code, they'll be very much biased and not be critical of their own code.
<neuro_sys>
TDD in the strict sense is not quite compatible with Agile, I think. OTOH, I think Agile is a conspiracy.
<boru>
The problem is that project managers want to shoehorn the methodology du jour into everything, because it's all they know.
<neuro_sys>
Yes, blindly employing theories by the book is the problem.
<boru>
I agree. I don't think anyone actually thinks agile is good, and I've yet to come across a shop that follows it to the letter.
<mstevens>
Yeah, my TDD mistakes came from applying it a little too blindly.
<neuro_sys>
The problem with the corporate/business mentality is to have recipes that fit for all people (basically seeing them as replacable resources that fit a template). There's no escape from the fact every individual is different, and every team is different.
<boru>
TDD, programming by contract etc. all had their hay day, and they probably do work well in specific requirements, and taking the unilaterlly good features of them is sensible, but it's not one fit for all, alas.
<boru>
Yeah, I agree with you there again.
<mstevens>
boru: I've never had the chance to use design-by-contract languages like Eiffel but it feels like an underrated area to me. Probably useful.
<neuro_sys>
A bit unrelated, but I'm curious about formal specification languages like TLA+.
<boru>
You can do it with any language, and yes, I've generally employed the concept with respect to solidifying interfaces before implementation such that people can work in parallel, and have less of a headache at integration etc.
<mstevens>
neuro_sys: I've read a lot of positive stuff and am also curious.
<boru>
Not just parametric contracts, but timing envelopes and whatnot for hard real time stuff.
<boru>
IME, most methodologies have gravitated towards the spiral model over time for a particular project.
<boru>
Even for one shot deliverables.
mtsd has quit [Quit: Leaving]
<boru>
Iteration is good, themed phases are good; less chance for people to be changing requirements in the design, or worse, implementation phase.
<neuro_sys>
Again slightly unrelated, what do you think of rewrites?
<boru>
In what context?
<neuro_sys>
In any context that you might have to be faced with the decision of that a rewrite of an existing software seems necessary.
<neuro_sys>
As an example, the software is no more scaling (in whatever terms, let's say, adding more features is not possible, or the throughput is limited).
<boru>
Yeah, I've experienced that in its entirety or just isolated modules.
<neuro_sys>
The choice of an important stack is not fit for the requirements any more, etc, and has to be changed, which necessitates a rewrite. Things like that.
<boru>
In the infamous workds of BWK and PJP in TEPS: "don't patch bad code, rewrite it"
mtsd has joined #forth
<boru>
Yeah, I've come across that fairly often. More frequently when something written as a feasibility study becomes adopted as something to be shipped because some manager heard the word "finished".
<neuro_sys>
In my last project I pushed for a rewrite with a lot of resistence, it was stressful, but the rewrite itself wasn't.
<neuro_sys>
In the middle of the implementation, a colleague argued his way into "reducing the scope" by limiting the rewrite into "let's split the monolith, and rewrite only one half", but thereby making the scope larger.
<neuro_sys>
That's where I failed and said, okay, let's do that.
<neuro_sys>
Anyway, with the good and the bad, I've learnt quite a bit on that one.
<mstevens>
I'm really reluctant to do total rewrites, because I've seen them take ages and lose half the features of the first version, but it depends a lot on the situation. Things like rewriting well defined components make more sense.
<neuro_sys>
All in all, it was rewritten and everyone was happy with the end result in the end.
<neuro_sys>
It is indeed something to be reluctant unless it seems to be the only way out.
<mstevens>
One common problem is where the rewrite is handled by a separate team and the knowledge from the first version gets lost.
<boru>
Yeah, sometimes you can feel a bit like Sisyphus in that respect. Luckily, it's sometimes been my call, or I've worked with management and colleagues who trust your call, or you have managers who are stubborn, but listen to reason if you come to them with sensible rationale for a re-write.
<boru>
It helps a lot if you have tests in place beforehand, like with all refactoring.
<mstevens>
On the other hand, sometimes something really is a disaster area and any attempt to change it gradually is more trouble than it's worth.
<boru>
Yes, that's often a good reason for convincing people, especially managers; they care about when things will be finished, so if it takes a lot of man hours to maintain something, then you can propose the re-write, which will save time in the long run.
<mstevens>
The trouble is devs will generally say the old version is a disaster whether it is or not.
<neuro_sys>
Yeah, speaking of tests, they should ideally be written in an isolated way. In the case of the rewrite I meantioned, the old tests were barely salvagable. But a nearly one-to-one porting of the code was possible.
<boru>
If something has grown organically, it usually is.
<neuro_sys>
What's your take on the necessity of type systems? I've been a huge fan of them, and Forth has been changing my opinion slightly lately. But for a real project I wouldn't still let go of the value of static analysis and static typing.
<boru>
The nice thing about programming by contract and defining your interfaces early, you can almost automatically generate your unit tests before you've even implemented the program.
<boru>
Writing tests is tedious, so if I can automate that sort of stuff, I prefer to.
<neuro_sys>
Do you mean by some sort of contract/interface defining language, and let it generate the tests as well?
<boru>
It depends. Type systems are nice, but where they're not present, it makes sense to use stuff like Hungarian notation in some cases, as much as Hungarian notation makes me violently ill.
<boru>
And no, not that. That's IBM-style.
<boru>
Typically, they've been defined in some sort of markup languages for wire protocols, or actual code for APIs.
<neuro_sys>
I would like to use something like that (automatic test generation), but so far I always write up a technical design document, and move on to implementation and tests afterwards all parties accept on the interface and sequence.
<mstevens>
neuro_sys: Lately I've been doing a lot of work with perl and python and getting frustrated with the "it takes an argument called foo, but what do I pass in for foo?" problem. I want to try out something with a really strict type system. I've actually been reading a bunch of positive stuff about Ada.
<boru>
I wouldn't bother. Ada is hanging on by a thread in aeronautics, but not for long, I'd say.
<boru>
And mostly defence aeronautics.
<boru>
It has some nice features, certainly, but I wouldn't waste time on learning it unless it was for fun.
<mstevens>
This would mostly be for fun.
* boru
nods.
<mstevens>
I'm also curious about ocaml. Must learn more things.
<neuro_sys>
Yes, one the benefits of type systems is the self documenting code in the form of annotations, which is quite nice when reading the code. Although in FORTH, it hasn't been much of an issue so far, then again, I've yet to read much of someone else's code :)
<boru>
I wish I had the time to learng something new. I've got too many hobbies...
<boru>
I mostly write C, assembly and verilog/vhdl these days.
<boru>
And glue stuff with awk and perl.
<neuro_sys>
Yeah too many things to learn especially in this day and age.
<neuro_sys>
boru: Is that for paying job?
<boru>
Yeah.
<neuro_sys>
That's very nice/lucky, recently for the first time I moved on to something I find interesting as a paying job, graphics programming.
<boru>
Implementing forths is a hobby for me.
<mstevens>
I've done a lot of perl for $job and I'm worrying my skills are a little obsolete, so I need to update.
<boru>
As well as many other things.
<neuro_sys>
But I feel more at home and enthusiastic about low level systems work, which I have no professional experience.
<boru>
So why not apply for something anyway?
<neuro_sys>
I just did that for a graphics programming job, and will see how I like it.
<neuro_sys>
After that I'll see which route to take.
<neuro_sys>
Perl indeed sounds so 90s-00s
<boru>
I spoke to another person in this channel about that subject; I've hired quite a few people who had no degree in a relevant subject, but plenty of hobby experience, knowledge and interest.
<boru>
Well, I'm a bit stubborn with my preference for Perl. It does everything I need it to, so I haven't switched. Plus the python community really put me off learning python.
<neuro_sys>
A degree is usually 4 years, but hobbies can be a lot more than that!
<mstevens>
neuro_sys: My company love it though, so it's hard to get other stuff in. I've managed to do some go for stuff that's more performance critical.
<boru>
Degrees aren't really very interesting to me. I'm generally interested in people who do things in their spare time, or have interesting projects they can talk about and answer questions about.
<mstevens>
I actually like what I've seen of the python community. I used to like the perl community but I've changed my mind (or maybe it's because I also liked perl more at the time).
<neuro_sys>
Of course when hobby matches with the academic education that's ideal.
<neuro_sys>
Although I suspect too much time in academic studies may mean someone should stay in theory, and not deal with the ugly reality.
<boru>
It depends on what they would be doing.
<neuro_sys>
True, research is research.
<boru>
Anyway, I had better get back to work. Long story short, don't be put off by applying for something that interests you. If you can create a CV which will get based HR pattern matching drones and sit down in front of some engineers, you might be surprised.
<neuro_sys>
Thanks! I will most definitely do that in the rest of my working life, that is, only pursue what interests me rather than financial safety.
<boru>
I'd say do whatever pays the bills. If eventually it happens to coincide with what you like doing (which it most likely will), then go after it. But the sooner you make the switch, the better.
<boru>
(From a financial perspective, that is)
<boru>
Hobbies can always be hobbies so long as you have a roof over your head.
<neuro_sys>
This guy who writes retroprogramming.com often mentions that he's not a programmer by trade, and he doesn't like it. Yet he's doing it as a hobby and doing whatever he likes. Depending on what's his main job, it sounds very appealing to me.
<boru>
I can relate. Hacking is fun. Sometimes it's just nice to write programs without restrictions. To be filled with Tao, as Geoffrey James wrote.
<neuro_sys>
It's a bit obscene/improper to talk about it, but recently I was very fortunate with my previous company going public on the stock market, and the sales from that, so in a sense that paid off doing something that's not my main hobby. Now that gives me a lot of flexibility about what to do next with less financial concern.
<neuro_sys>
Now I can freely FORTH away
<neuro_sys>
Doing a job that's not your main hobby, and in your free time working on other things feels like a guilty pleasure, and somehow not right.
<neuro_sys>
I often had times coming back from work and starting the next job (which is just hobby) and working for another 6 hours.
Monev has quit [Ping timeout: 268 seconds]
<neuro_sys>
Which makes both the main job and the hobby very inefficient.
<boru>
Yeah, having a non-computer-related hobby to break things up is good.
<boru>
Take up astronomy, or learn to play the piano, or something.
<neuro_sys>
Astronomy sounds interesting, and tangentially related to Forth
Monev has joined #forth
<proteusguy>
For fpgas and electronics design - you can implement formal methods in an agile fashion. It's all about incremental delivery and getting past the hard stuff asap to confirm your design is valid and your implementation will meet the spec.
<boru>
You can implement formal methods in an agile fashion for anything. It doesn't mean it makes sense to.
<proteusguy>
boru, my argument is that it would make sense. Helps determine the order in which you do your design & implementation. Also keeps the project "on track" or gives you early warning if it's going astray.
<boru>
I've had this discussion several times with several people. We're not going to agree on its suitability.
andrei-n has joined #forth
<proteusguy>
boru, I think you're talking about "Agile" (TM) branding rather than the true architectural drivers of agile, the style.
<boru>
You can think what you like, I'm not interested in discussing it for the nth time.
andrei-n has quit [Remote host closed the connection]
andrei-n has joined #forth
andrei-n has quit [Remote host closed the connection]
andrei-n has joined #forth
andrei-n has quit [Remote host closed the connection]
andrei-n has joined #forth
f-a has joined #forth
f-a has quit [Ping timeout: 246 seconds]
X-Scale` has joined #forth
X-Scale has quit [Ping timeout: 265 seconds]
X-Scale` is now known as X-Scale
ovf has quit [Ping timeout: 246 seconds]
ovf has joined #forth
dave0 has quit [Quit: dave's not here]
tech_exorcist has joined #forth
f-a has joined #forth
f-a has quit [Quit: leaving]
<KipIngram>
That sounds completel reasonable to me, proteusguy. And I do feel that many of
<KipIngram>
the practices of agile are good - I find the cheerleading, "rah rah rah" aspect
<KipIngram>
a little silly, but that doesn'nt mean it doesn't work.
<KipIngram>
I'd gotten through most of the training with only a few minor eye rolls, when that bomb got dropped, and it really set me off.
<KipIngram>
I'm very sure good architectural planning could be EXECUTED in an agile way - I can't think of any reason why not.
andrei-n has quit [Quit: Leaving]
<KipIngram>
In fact, it occurs to me that what would probably have been best for the development of that young team would have been to let them do the architecture - have a few sprints up front the deliverables of which was "the plan." And I would have functioned as customer. That would have worked. It just would have taken a little longer, while they made errors and learned form them.
<KipIngram>
But it would have been very very good training.
<KipIngram>
The problem is we just barely got that work done every year in time for the trade show - we had no time to spare.
<KipIngram>
And ultimately it was a business - the goal was to satisfy the owner. It wasn't a product development training school.
<KipIngram>
But I just want to be very clear that I'm not slamming agile in general here - just the specific notion that a great architecture can emerge from a vacuum.
<KipIngram>
Somewhere in there you have to have someone who is experienced. Maybe he/she could function as customer instead of taskmaster, and you'd still ultimately get good results. But that function can't be absent.
<KipIngram>
And I do admit that if you have projects that don't have ultra-tight timelines, so you can afford that "traing element," then over the course of a few projects that would produce a truly kick-ass team.
Zarutian_HTC has quit [Ping timeout: 252 seconds]
Zarutian_HTC has joined #forth
<KipIngram>
Ok, now I see. I'd never really grokked how LISP worked - I understood the whole functional nesting thing, and assumed that somehow that was enough to get everything done. But now I find out about PROG, and it all makes much much more sense.
f-a has joined #forth
DKordic has joined #forth
f-a has quit [Read error: Connection reset by peer]
<DKordic>
I live...
f-a has joined #forth
<KipIngram>
This is a good thing...
<f-a>
I have bought an ivy, fuck yeah [/ot]
<KipIngram>
An ivy? Somehow I don't think you mean a plant.
* KipIngram
is clueless...
<f-a>
I do mean a plant
<f-a>
for my balcony
neuro_sys has quit [Ping timeout: 250 seconds]
<KipIngram>
Oh, well, okay then! I'll be excited with you.
<KipIngram>
I thought maybe it was some kind of new whiz-bank tech gadget.
<KipIngram>
bang
<f-a>
well my balcony was bare
<f-a>
and an ivy is literally 0 maintenance
<f-a>
and it is cheap as a cheap meal
<f-a>
so why not
<KipIngram>
Plants are nice - they make every environs seem more "alive."
<KipIngram>
My daughter planted a kick-ass garden in our back yard, just beautiful.
<KipIngram>
She was living here at home because she married an Army boy in December annd the Army had to process some paperwork before they could live together.
<KipIngram>
Only took them FOUR MONTHS.
<f-a>
super
<KipIngram>
But she just flew off to join him in Hawaii a few days ago and now I have to try not to kill her garden. :-)
<f-a>
how difficult is it to tend?
<KipIngram>
It's not that bad - I really just have to not be lazy.
<KipIngram>
Man, if you'd kept me from my wife for four months after our wedding I'd have been fit to be tied.
<KipIngram>
The main threat is rabbits, of which we have a nigh on unlimited number around the neighborhood.
<f-a>
well
<f-a>
the «reproduce like rabbits» has a kernel of truth, I suppose
<KipIngram>
We used to have a large German Shepherd, and I put a big dog run in on one end of the house. About 60' long and 5' wide. That's where the garden is now.
<KipIngram>
I lined the fencing with chicken wire, but the rabbits still manage to get in.
<KipIngram>
Rats too, but I think there are far fewer of them.
<KipIngram>
The shepherd passed way to young - best we can guess a poisonous snake bit him.
<KipIngram>
I'd just played with him for a good while the night before, and he was fine. I went to work the next day and my lawn guy emailed me and told me he was gone.
<KipIngram>
It was a real shame - he was an incredibly gorgeous animal.
<f-a>
rats too are stereotyped to breed like, well, rats
<KipIngram>
Yeah. I just see them a lot less often, though. Maybe they're just a lot less likely to venture out in the light.
<f-a>
hopefully you do not have pigeons
<KipIngram>
No, no pigeons.
<f-a>
see, there is always a good side to every story xD
<KipIngram>
Coyotes too, though. We have Yorkshire terrier now and I won't let her in the back yard by herself. It's fenced, but others in the community have had their small dogs taken from their yards by coyotes.
<f-a>
;_;
<KipIngram>
I think those neighbors are more on the edges of the neighborhood than I am, though.
<KipIngram>
I'm surrounded on all sides by several layers of housing.
<KipIngram>
We may have less of all of those things for a year or so now, though - a couple of months ago we had the worst winter storm this part of Texas has had in like centuries.
<KipIngram>
Single digit termperatures, for several days.
<KipIngram>
Very possible it impacted the animal population, especially the smaller things.
<KipIngram>
We lost power for a little over two days - it got down to 35 degrees in the house.
<KipIngram>
Thankfully our gas water heater worked, our gas stovetop worked, etc.
<KipIngram>
Ski apparel for the win, by the way.
<f-a>
hehe
<f-a>
I suspect that was in Farenheit xD
<KipIngram>
I'm going to wait until it's really hot weather this summer and all of the post-storm demand has settled, and I'm shoping for a whole house generator.
<KipIngram>
Yes, Farenheit.
<KipIngram>
Single Celsius digits is wholly normal for winter around here.
<KipIngram>
We usually hover just above freezing for most of the winter, with a couple of dips below.
<KipIngram>
It's the moisture from the Gulf in the air - makes it hard for the temperature to reach extremes.
<KipIngram>
I'm only about an hour from the coast.
pointfree has joined #forth
gravicappa has quit [Ping timeout: 252 seconds]
gravicappa has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
gravicappa has quit [Ping timeout: 265 seconds]
pointfree has quit [Quit: Connection closed for inactivity]
Keshl_ is now known as Keshl
f-a has quit [Ping timeout: 240 seconds]
f-a has joined #forth
tech_exorcist has quit [Quit: tech_exorcist]
lispmacs has quit [Ping timeout: 265 seconds]
Zarutian_HTC has quit [Remote host closed the connection]
Zarutian_HTC has joined #forth
f-a has quit [Quit: leaving]
<veltas>
siraben: So far Scheme is interesting, seems like the Forthier Lisp
<veltas>
And seems to have the same brands of drama as Forth