> On Aug 29, 2017, at 15:47, David Zarzycki <zarzy...@icloud.com> wrote:
>
> Hi David,
>
> To add to what I wrote earlier, the design of the Swift is such that adding
> new features isn’t “hard”, but it does require time and patience because most
> new features have ripple effects on other parts of the compiler that need to
> be thought through. Fortunately, the design of the compiler is such that vast
> majority of those ripple effects will cause a compile time failure. This is
> why I encouraged you to add new “.def” nodes up front. That’s the good news.
> The bad news is that you still need to think through the ripple effects and
> that means developing some minimal design and debugging expertise over the
> compiler as a whole. If you’re not discouraged by the process, the experience
> is quite rewarding.
Not from that, no. All the meta-programming stuff in the .def files (and the
enums that reference them) is still hard for me to follow, but I'll figure it
out, and it takes more than mere confusion to discourage me. :-)
Honestly, the relative difficultly of getting a working dev environment going
is *way* worse than trying to figure out how to implement a feature...
Somewhere along the line today I synced my repo with Apple's to make sure
nobody had refactored the type system or something while I wasn't looking, and
unknown to me until a few minutes ago, the newest version requires Xcode beta 6
to build, which requires macOS 10.12.6. Well, I'm still on 10.12.5 because
10.12 doesn't support my 2008 Mac Pro at all (even though everything except the
wifi works perfectly... in fact better than 10.11, at least for me), so
updating the OS is a huge hassle... you've gotta jump through a bunch of hoops,
else you'll end up with a boot volume which has incorrect (yet strongly held)
views on whether your computer can boot off of it. Having stuff suddenly fail
to compile after you've been mucking in files that you don't understand yet
(*.def) -- even after saving copy of the files you were editing then telling
Xcode to discard all changes -- is enough to make you think you somehow messed
something up. Then you delete everything in the "sources" directory, and spend
3-4 hours or so starting over with an attempt at getting a clean install/build,
only to notice halfway through that it's not going to work because now the
compiler needs a newer version of Xcode (does it really, or does it only need
the newer command line stuff?).
Anyway, not knowing an easy way to tell if the problem is in your code or the
dev environment, and not knowing how to fix the problem if it is in the
environment (short of spending 3+ hours hoping that following the directions
from the top will make everything happy) -- that can get discouraging.
> One more tip: if you’re going to add a new language feature, focus first on
> the type system and writing tests. Once you feel that implications are fully
> thought through, you can move on to “code gen” (i.e. SILGen and IRGen). If
> you rush to “code gen” first so that you can play with your shiny new
> feature, then you’re likely to get frustrated by self-inflicted bugs. You can
> experience the blissful pre-code-gen world by invoking swift like so: swift
> -frontend -typecheck file.swift
Sounds like good advice... I think I'll experiment with that tomorrow, after I
figure out how I'm going to get beta 6 running.
- Dave Sweeris
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
