See. Goes to show you can't complain both about lack of expressivity and "lag" in a PL.
Actually,I am just angry in the snap lag when I am making stuff that has a O(n^4) stuff in a warp in a huge forever loop
I am not angry with the lag of doing macros(they dont quite lag)
I'm sorry if Snap! and my architectural decisions makes you and @sarpnt angry. However, I'm taking it as an indicator that our job is done and you are well endowed to complain to the makers of professional programming languages about what Snap! provides that they don't.
In hindsight,I probably should expect anything bigger than O(n^2) to lag
Yeah macros are great
we dont want to parse strings and parse strings and never ends
do you mean me? because the reason i was interested in snap is to be able to make things that less experienced people could mess around with. that's the way i've approached scratch for years, to inspire people and give them readable code, but if a project gets too complex it isn't readable in scratch anymore, i was hoping snap would be reasonable.
i thought you wanted technical projects? why are you just telling people to get off snap?
who? i don't program in python.
this still really sounds like to me that you're grouping me in with them, i'm not them.
snap dissapoints me because it looked like a good tool, and had issues. what really annoys me is your attitude towards the people that actually want to use it to make new and interesting things.
if you really think your job is done and want "overenthusiastic nerds" to go away:
- get rid of suggestions on the forum. it's already done!
- get rid of share your projects on the forum. students can show their teachers
- get rid of TOTMs. students have a curriculum, they wouldn't be doing that
- stop being annoyed that projects you want to see don't exist, they're esoteric and fringe
- tell bh to stop recommend complex project ideas, they lead to esoteric fringe topics
i really think you need to actually decide who you're making snap for and make it clear it's for them specifically.
Why Isn't Snap a professional programming language? The answer is quite simple, is that is WELL beyond Snap's design parameters. Snap is meant to be, primarily a teaching tool and experimental sandbox. You're meant to play IN the sandbox not build things outside the sandbox, even if they help inside said sandbox.
That said, I do think that there should be a "professional" programming language driven by blocks, because well, if you're teaching a kid to code from age 5 with Scratch Jr and then Scratch, and then maybe they discover Snap! then for ten or so years they've been using an environment that makes a lot of sense to them and then saying, after that "Time to switch to a REAL Programming language. Nub. Good Luck" and then introducing them to the full scale train wrecks that make up those languages?
If you want to know why the drop between Scratch and Snap is so huge, let alone the amount of kids who just never code again after scratch? You show them Python or C or *Programming mess name here" and they'll rightfully look at you as if you've lost your mind.
This has been my goal for a while, a block language that runs native and can compile.
The reason I think this is is simply that programming with your hands in mixed/augmented reality via blocks is a necessary next step in the evolution of programming and that the need to cling to text languages is a destructive habit.
Mind, that's not what snap is for.
I'm bad at coding though. I've been using computers for a long time and i can navigate a UI/RTM just fine, but text strings? Brain is too broken for me to do that. I greatly enjoy reading other peoples code in snap, but when ever I open the interpreter to a blank page, all my knowledge flies out the window. Gawn.
That's a ME problem though. Otherwise I would have done it myself. I still eventually do plan to do that though, it's just going to take a couple dec... centuries... millenia...
i never said i expect snap to be a professional programming language? what you're saying isn't at all what i want.
Everybody is welcome here, I don't want anybody to go away, unless they profess "anger" and "disappointment" at Snap! or "annoyance" at me for not prioritizing their desires over those of others. In those cases I suggest slowing down and taking a break rather than turning up the volume.
Snap's raison d'être is UC Berkeley's CS10 class and the BJC curricula in their various flavors, including the Microsoft TEALS Introduction to CS course, as well as to support a dozen or so other industry, college and high school curricula and research projects. We try to make Snap welcoming and interesting so it can serve both kids and computer scientists, and also safe and predicable, so teachers feel comfortable and supported, e.g. in configuring and customizing specialized learning experiences. Some fruits hang lower than others, somer higher-ups are riper than those already in reach. So we talk to or stakeholders and glance over our long term plan and make compromises. And yes, we're also always doing everything out in the open. Every. Single. Code commit. Including every mistake and every blunder. Every little change is out there on Github for people from all over the globe to take notice. And troves of people take notice. I firmly believe writing software openly and even publicly is not just nice but right. But Lord have mercy on me when folks become so enthusiastic that they first get impatient then disappointed and finally angry because I cannot immediately fulfill all their wishes. Or because they misunderstand the - purpose of - some feature. Or because what they want conflicts with something more important.
i don't care what your goals with snap are, it's your project. my issue is that you've said before that you're dissapointed you're not getting certian kinds of projects when it doesn't seem like you're catering to the kind of people that would make those, and claiming snap is "done" yet setting up everything
i can't tell what kind of support you're trying to give different kinds of people because your expectation and actions seem to constantly conflict with eachother.
if snap were a teaching tool only, that would be fine. if it was primarily a teaching tool, just with some sharing features as a nice spot for a community that likes it despite issues, that would also be fine.
and i'm CERTAINLY not endorsing the behavior of most people in the forums, and they don't speak for me. i don't think my actions on the forums are always a good example either.
I think people, even Jens but especially other people, should stop declaring what Snap! is "meant to be." Snap! is meant to be whatever users think to do with it, while recognizing that some user goals are incompatible with each other.
It's also true that BJC is the 800 lb gorilla among our users. Use by BJC students is way higher than all other uses put together. So we have to think about BJC first. But I don't think the discussion here is really about ways in which BJC holds you back.
When I started working on programming languages a million years ago, everybody made fun of Lisp as being of interest only to ivory tower computer scientists. Today, people out there in the real world still make fun of Lisp. But their "mainstream" languages all have garbage collection now, and they all except for Python have lambda (anonymous functions), and the most popular ones have untyped variables (that is, variables that can hold data of any type), and they all do tail call elimination (although not necessarily in the hard cases), and really the only Lisp feature that mainstream programmers can't use is macros. (They have something they call macros, but they're really don't have anything like the power of Lisp macros.) Snap! is still ahead of the curve by supporting APL-style array handling.
And so, if you decide to program in some other language, that won't be the disaster for your education that it would have been 20 years ago. If you still want a block language, it's because of its interactivity, which is another word for slowness. (I'm being sarcastic in that last part.) Some things are fast in Snap!, while other things are slow. More things are fast than five years ago! So, overall, we're moving in the right direction.
If you build a block language that compiles into machine language, you won't get the whole interactive development environment with sprites and all that, and the ability to grab a sprite and move it somewhere else by hand and have the program keep running. Having said that, there's always Blockly, which does what you're suggesting. I guess it doesn't compile into machine language, but it compiles into a number of "grownup" languages that do compile into machine language,.
Snap isn't "done"! When individuals in this forum can eloquently express their metaprogramming woes "our job" as educators is "done" and it may be time for them to graduate to systems that don't reign them in. Get it?
And by the way, when you're using a language with a staff of 20 paid programmers and another 50 volunteers, and you complain about something in a jokingly (or not) insulting way, you're not insulting anyone in particular, and the team can let it wash over them. But Snap!, both in design and in implementation, is still basically a one-person project, and people (not anyone in particular, so don't anyone get defensive please) might want to keep in mind that if you insult Snap! you're attacking one person's life's work.
my point is that how snap and the sites around it are set up, and what jens seems to expect users to do seem to conflict with eachother and themselves.
the things i make on snap aren't for me, they're for others. i can't expect others to have a fast computer, have access to a computer with the various programs needed for text languages, how to set that all up, or to know all the correct things to type for a regular programming language. what i was hoping snap would be able to do is handle an area where scratch is too cumbersome and complicated, but still has the accessibility and remixability for people who are still learning or want to start out.
fair enough, i misenterpreted what you meant, sorry. i still have an issue with the post you've sent before where you were talking about how there aren't all sorts of different projects like scratch has. if you want people to make various complex and interactive projects, you aren't going to get it by telling people to move to a different language, they're simply going to make it in that different language.
i'm not trying to demand that you make changes in any particular amount of time, but i find the goal unclear. what do you actually want from snap and what are you planning to do with it to get there?
if i don't know your goals, i can't know what you consider helpful or annoying bug reports, what kinds of suggestions you care about, or what code i could contribute that you'd appreciate, not care about, or even consider insulting in some way.
as an example, i don't know if you would consider it useful to change a large part of how the code works for a speed improvement. i don't know whether you find the speed boost useful for projects, or too difficult to continue working on because you might not understand it or simply not like the coding style.
Again, I'm sorry if Snap! is too slow for your projects. Bug reports are mostly welcome, I usually try to address them right away. Sometimes we disagree whether something is a bug or a (mis-) feature and in those cases trying to coerce your opinion on me through forum polls and spam threads is a sure way to make me mad.
Ideas for optimizing things are mostly unwelcome because over a decade of such suggestions has shown time and again that those who propose them are rarely seeing the full picture and it just bogs me down to explain the architecture all the time. Snap is free and open source, but my time and my attention span aren't. And talk about "changing a large part of how the code works for a speed improvement" will almost certainly make me lunge at your throat.
I'm not interested in discussing implementation and optimization details here. That's an understatement.
i don't ever remember making forum polls or spam threads, are you thinking of someone else or is this just an example? the closest thing i can remember is when i was talking about a lot of things relating to stopping/pausing scripts and ring environments, it turned into a complicated tangled mess of terminology where i felt like i never described things properly or was understood.
and to be clear, i'm not talking about suggesting that you look into these issues and fix them. you're clearly busy. i'm talking about pull requests, where the code work is done and reasonably tested, and any important changes are described.
Those used to happen a lot. I'm talking about my pain points here, not about what you're doing or not, trying to explain what pulls my strings.
Snap! is open source but mostly closed development. Among the colleagues I trust with contributing code we discuss everything, aside from them unwarranted pull requests by the community rarely make me happy, mostly when they're a really short and clever solution to a real problem. In general needing to review other people's code is an unwelcome disruption for me, on roughly the same level as having to attend a business meeting.
And this is also the point at which I'll stop participating in this thread. I'm trying to finish a new release for the end of next week, and getting unpleasantly sucked into this forum mire bogs me down.
i never said i expect snap to be a professional programming language? what you're saying isn't at all what i want
Sorry, I should clarify, My answer to you was the first part and then I jumped into what I want from a programming environment. Snap is definitely, for me a starting point, that I can't quite figure out how to turn into what I want
I think people, even Jens but especially other people, should stop declaring what Snap*!* is "meant to be." Snap*!* is meant to be whatever users think to do with it, while recognizing that some user goals are incompatible with each other.
Yeah, that's what I was trying to drive at. It's primary use case is teaching, and using the capabilities available to go "I wonder if" and then prove/disprove that. Teaching yourself how to do things.
My problem, is I have a stupid powerful machine and don't really like how Internet Browsers have become secondary Operating Systems, but bad at everything and that every time I try an "actual" dev environment like for example Visual Studio code I think to myself "Sure, the wizard did it, but how did the wizard do it?" and the documentation boils down to "The wizard did it"
Is that a ME problem? Yes. Can those ideas be expanded upon in a much better way? Yes.
How? No idea.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.