Must...resist...the...urge...to...post...Arg!
Printable View
Must...resist...the...urge...to...post...Arg!
lol....you say this as if this is surprising. I started programming in BASICA, then QuickBasic replaced it. I moved to that. Then Windows was becoming a thing and I moved to Visual Basic 2. Later on there was VB4, I moved to that. Then I started in VB6. VB.Net later replaced VB6 and I moved to that. Whatever comes next, I will move to that to. So tell me, what is the big deal ? I've been moving from one to the next for decades.Quote:
Originally Posted by MikiSoft
Personally I think VB as a language has become stagnate. And has been for some time. I think that real change to the language itself was the Line Continuation character removal and the Default Properties... back in, what 2008? Everything else has been pretty much framework additions/updates. And that's actually the beauty of the FW and .NET... additions are added to the FW, not the language itself. It's far easier to add something to the FW than it is to the language itself. That's how we end up with a new FW version every couple of years. But the language itself... there's really not much left there to grow. It's how the C#/VB.NET parity has been maintained (except for XML-Literals). All they have been doing lately is adding to the Framework and adding features to the IDE. But the VB language itself hasn't really evolved a whole lot in the last few years.
-tg
on a side note, here's my progression of learning:
Apple BASIC -> LOGO BASIC -> GW/PC BASIC -> BASICA -> Pascal -> QBasic -> Assembler -> ADA -> Assembler (again) -> COBOL -> FORTRAN -> VB3 -> VB4 -> VB6 -> C# -> VB.NET
There's been a smattering of others along the way like JS, HTML, SQL, PHP as well...
-tg
Well I'll be damned, they're actually considering it:-
I guess I'm going to have to eat my hat!Quote:
Nobody who hasn't lived under a rock for the last 15 years can have failed to notice the on going discontent with Microsoft's decision to abandon the classic Visual Basic platform in favour of .Net. A hard core of classic visual basic aficionados have been campaigning ever since for Redmond to allow the prodigal son back into the fold and it seems they've finally listened.
In a statement Paul Yuknewicz said "We've always felt that Classic VB was awesome but didn't feel it would be cost effective to maintain on going development of the language. However, the huge support we see in the community demonstrates that it is worth taking a second look at whether there is a low cost way of delivering it.
bad bad man :DQuote:
Well I'll be damned, they're actually considering it:-
lol...can't believe I believed that. Good one.Quote:
Originally Posted by FunkyDexter
That's a hoot.
No one pollute... Shaggy gave a hoot.
Someone asked me one time if I wanted to go to something that was going on (this was a looong time ago), I replied "Sure, it'll be a hoot." ... pause ... "What's a 'hoot'?" ... "It's like a gran' ol' time only better." :)
-tg
Hoot may be short for hootenany. Or hootenany may be long for hoot, since it sounds kind of made up. If you want a definition, you'd probably have to ask DDay.
Gotcha!Quote:
can't believe I believed that.
I was hoping for a few VB6ers, though.
No doubt you must have caught a few but they're probably remaining silent. I would I were still a staunch VB6 fanboy :DQuote:
Originally Posted by FunkyDexter
The VS language suite and supported environments are definately evolving.
Node.js Tools 1.0 for Visual Studio
While a struggle, at least they struggle to remain relevant over there at the Tools Division. It even integrates Anders' new hobbyhorse TypeScript.Quote:
Node.js is a platform for building fast, scalable applications using JavaScript. It’s making its way just about everywhere – from servers, to Internet of Things devices, to desktop applications, to who knows what next? And now, with Node.js support in Visual Studio, it’s easier than ever before to develop Node.js applications.
Now that looks very promising.Quote:
Originally Posted by dilettante
I didn't even know what Node.JS was until just now.
Interesting...
Do I really want to write all my code in a JavaScript like language?
Since leaving WinForms for web apps I have really started to appreciate the separation of the browser for UI and web methods on the server.
JavaScript really shines in the browser working the DOM and AJAX'ing away.
I see no reason to leave IIS and the .Net framework on the backend. And if I really wanted to leave IIS I would just code my own HTTP listener and work my homegrown web methods directly (and still be in .Net).
I certainly don't need a JS like language on the server to work the JSON. It turns into a dictionary-like object in .Net and is totally accessible.
The Node.JS benefits of single-thread server side execution isn't something my enterprise-users need (they simply don't scale to thousands of requests at a time). I don't mind each session getting a server-side thread - windows is all about threads - and the IIS engine recycles regularly for cleanup.
I wonder if the Node.JS single-thread on the server can be exploited between sessions? I know I've had to create a whole bunch of logic to manage session security and separation in my own web methods - not something trivial.
ASP.Net (and .Net in general) is the past. There usually isn't any compelling reason to rewrite existing legacy code, but when a move makes sense you should be ready.
It has already been shown that a move from ASP.Net to Node.js brings performance improvements and has far lighter server requirements as well as being portable to other server OSs.
And while JavaScript is a sucky language, it isn't much worse than either VB.Net or C#.
There is no need to raise bogeymen such as security, just look at some of the large players who use Node.js:
https://nodejs.org/industry/
That's even and old list, and many more have made the move in the last two years.
Your boss needs to read Why Node.js is becoming the go-to technology in the Enterprise
Time to look for a lifeboat, .Net is a sinking ship.
Like I said I'm stuck in an enterprise world giving my clients brand new access to their decades of MS SQL data. They are more interested in having the app create a proper .XLSX file and at the same time being able to work it from an Android device.
LinkedIn and PayPal are no comparison - different world. From their comments they embrace the JavaScript language - something you just derided.
Matter of fact your last post talked down ASP.Net, .Net. VB.Net, C#
Made some comment about re-writing legacy code - not sure what that was directed at. Are you stuck re-writing legacy code?
I don't have a boss - not sure what that means.
And my point about security came to mind when I saw that Node was created in 2009.
@dill - do you think that IIS is only about traditional ASP.Net with that mixed up HTML-plus-ASP-markup and partial postbacks and update panels and all that stuff?
Have you ever coded an ajax-with-callback function in JavaScript and seen that run in debug in Firebug?
@dill - Have you ever coded a web app where multiple users were going to perform operations like uploads and downloads and have to create temp folders and "pretty-named files" for download on the server?
btw - google around for NODE and security and it's no bogeyman.
@dill...
Quote:
An honest look and I feel node isn't meant to be used as is. With a strong framework, is how it should be used. There are many in the fray right now - Express probably is the most widely used. I haven't tried it yet but
from what I see, security in node is a work in progress.
And the sky is falling, too.Quote:
Originally Posted by dilettante
C# and VB.Net as languages are far better than JavaScript. They aren't even in the same league. C# in particular is what I think JavaScript should have been. C# is very elegant and expressive while retaining the advantages of a statically typed language.Quote:
Originally Posted by dilettante
Christ, not this again :sick:Quote:
Originally Posted by dilettante
Ab-so-lutely.Quote:
Originally Posted by Niya
The ONLY thing going for JavaScript is that it's a client-side language. The only thing. It's also lightweight (but the reality is that no-one actually cares about that, as long as it just works). Having said that, that one thing is a hugely massive thing which keeps attracting developers.
It really is a horrible language to develop in, even though quite a few have 'mastered' that art of hammering screws. The 'plug-in' like functionality is what really took the whole thing off: I'd say most developers (sic) in JavaScript depend on plugins (aka. other people's work) for a significant portion of their JS programming.
You mean plug-ins like jQuery ?
My web app is 11,000 line of my own JavaScript. Calling about a dozen or so web methods (.Net) for all the variety of CRUD and other DB / system operations needed.
The web methods are the most static part of the whole operation.
My JavaScript code calls those web methods to build up the web page with what appears to be tabs and grids of data and whatever the user requests. All AJAX - page never re-loads. Not your typical IIS app.
The same web app is used by all my clients - tax collection in PA, municipal admin software in MA, labor unions, social workers.
Using jQuery is like using any other library - jQuery tricks out CSS identifiers in a really powerful way. I exploit that by doing things like putting a CSS class of "awc-xxxxxxx" on any DOM element which then causes it to auto-bind to some database record element of "xxxxxxx". That auto-bind type logic is all my own JS code.
jQuery gives you neat controls - datepickers, auto-complete lookups and such.
If I need a grid, why not use the powerful SlickGrid - great grid functionality and totally extensible. And since it's my own homegrown JS UI code and .Net web methods I can "store" the column info (heading text, DB mapping, UI tricks...) for the SlickGrid's in the SQL database itself.
When one client asks for graphs and charts why not use some nice library like jqPlot - instant cool HTML charts.
I get to write one "set of functions" in my JS app to turn a SlickGrid "data source" into a source liked by jqPlot and I've got charts for all my customers.
No reason to re-invent the wheel when this basic stuff is handled for you allowing you to focus on functionality for the end-user.
And all my clients benefit from that work - all getting the enhancements requested by everyone else.
Clients pay 15% annual maintenance. Giving them new functionality that's funded by other development work that I do for other clients is good business sense.
Been doing this since on my own as an ISV since 1986 - PDP/11 BASIC; VAX/11 BASIC, DIBOL, COBOL, ASSEMBLER; VB6; VB.Net; JS; C#; C++
Add in lots of HTML, some XAML, some WPF
Made telephone call-in bulletin board apps for high schools with VAX/11 BASIC and Dec/Talk machines in mid-1980's.
Made a VAX/11 BASIC report writer (like Crystal - but on green-screen dumb-terminals) in the 1990's - sold it dozens and dozens of times (you could charge a real lot for software apps in the 1990's - things have really changed).
Made pocket PC apps with ".Net compact framework" for Phys Ed teachers to administer President Fitness awards - in the field - in the mid-1990's- all VS and .Net.
Making Android apps with Eclipse/Java-whatever it is talking to those same .Net web methods that my JS app talks to (now that's code and platform re-use!).
It never makes any sense to me why people would want to lock themselves into a singleton relationship with some dev tool like VB6.
People should be concerned about building up their suite of knowledge - how to CRUD, how to UI, how to validate, how to FTP, how to AJAX.
It's the bag of tricks that makes a developer. Being able to use those tricks in lots of lots of languages and platforms and being able to research for best practice is a hat trick I would hire in a New York minute.
I don't have a particular problem with JS as a language.
I do think there's a lack of decent development tools though. I'd kill for a decent ide to ease me through it. I also don't like that it's not type safe though that's a criticism you can level at any scripting language and I know a lot of people actually prefer that. Finally, I don't like the way it swallows errors when I make a mistake in a web page - that can make debugging hell. The only one of those three that's a real big deal is the lack of an ide and I'm not sure you blame that on the language.
That said, I really haven't played with it for several years and it's likely my opinion is completely out of date.
Its dynamic type system makes it truly a chore to debug. Its not worth the advantages you get.
I have a habit of coding by creating snippets of code and running it through and checking watch windows and such. I've had that habit since the days I had to code on a paper devices (pre screen devices).
With that said I don't mind what I lose for strictness with JS over something like a VB.Net heavily typed language.
There are some truly great benefits that I've found as I've gotten into creating commercial products with JS. And to think that my heavily invested WINFORM customers have embraced the browser world - truly great stuff.
Mendhak predicted I would go "all browser" many years ago - he was certainly correct.
I also do this, perhaps not as consistently as you do but I do it regularly enough. Yes it helps yet I still find dynamic type systems to be a chore. You have to put so much more effort into debugging, even for snippets. When a piece of code doesn't do what you expect it to do in a strongly typed language like VB, at least by default you can eliminate certain possible causes. In JavaScript when you get funky behavior, and you can't say right there for certain what is causing it, you have to go more in depth. That means single stepping, checking variables, flow control etc. Having to make sure that you didn't change a dynamic variable's type during the execution of a piece of code is something extra you have to check for that wouldn't even be a concern in a strongly typed language. I hate that to be honest. I also hate hate hate the way classes work. Classes aren't strongly defined but rather defined at runtime. I don't know why anyone would think such a design was a good idea.Quote:
Originally Posted by szlamany
However, I get why some people might love JavaScript. You can write some truly elegant code in it. The dynamic type system in combination with first class functions can be used to create some amazing works of art. Its just the debugging I can't stand. To be fair though, I haven't worked that much in JavaScript. I played with it for a couple months a couple years back. I haven't touched it since.
@szlamany I love hearing about your projects. I do strictly web development but on the PHP/MySQL side. I have slowly been integrating more and more jquery into my applications, however most of my "modules" (if you will) that are in my portal systems are using the traditional page refresh.
I love to hate javascript. I tried out node.js once and I just did not care for it. I am just used to using javascript as a front end element rather than a backend element.
No way in hell I'd ever consider using JavaScript for any kind of back end development. Hell, I'd rather use VB6. JavaScript is good at what it does, which is to manipulate your browser but its really a terrible language if you plan to use it like a true programming language.Quote:
Originally Posted by dclamp
Another thing is that I find JavaScript doesn't lend itself well to modularization. Always ends of as bunch of files with a bunch of functions. This can very quickly grow to be unmanageable. I suppose one can use the Visual Studio IDE to mitigate this by utilizing folders and regions and such but the language itself doesn't provide what you need to properly organize code. Its like programming in C(not C++ which has classes).
Thanks!Quote:
Originally Posted by dclamp
FireBug shows the exact line of those hidden errors - just set a break at that spot and re-do the operation and you are right at it.Quote:
Originally Posted by FunkyDexter
My whole recent involvement in this thread was because of Node.JS being mentioned. The proponents of Node talk about having a single syntax across the stack - like that is a good reason to go with it. My backend remains .Net because that library/framework is so well laid out and programmatically accessible. That's enough of a reason to leave VB6 behind - talking to the API from VB6 required knowledge of that stack's particulars. And it's not like you have to be fluent in the API-speak. Just enough knowledge from posts around the internet and you are sub-classing your way around your VB6 with total disregard for proper practice. And god-forbid you subclass in the ide...Quote:
Originally Posted by dclamp
I agree with you right up to the end - "like a true programming language". That's a big statement.Quote:
Originally Posted by Niya
My backend turns CRUD calls into JSON that the JavaScript front end must then translated into DOM changes. I'd say that 90% of my UI code is in JS.
When I did my last UI - in VB6 - it was 100% VB6. I got a decade of use out of that app - served me well.
Based on how happy my customers are as I migrate them from VB6 to my new web-app, I've got another decade of happy clients.
You mentioned classes and functions and source organization.Quote:
Originally Posted by Niya
Look at this JS code:
Here I am setting a VARIABLE equal to a function. That's a class.
I have variables in that function - they are private.
I have private functions in that function...
Now those private functions end with a RETURN statement that GIVES back to the instance of this class a series of METHODS - LOAD:, CREATE:Code:var grid_maker = function () {
var gmOffset = -1;
var gmNameSeq = 0;
var windowOn = false;
var parentInfo = {};
var i_set_current = function (i) {
var intGO = g_objGMaker[gmOffset].parentInfo.baseGO;
g_objGrid[intGO].reader.gminfo.gmcurrent = i;
};
var i_set_showlist = function (b) {
var intGO = g_objGMaker[gmOffset].parentInfo.baseGO;
g_objGrid[intGO].reader.gminfo.needlist = b;
g_objGrid[intGO].reader.gminfo.checkneed = false;
};
var i_set_layout = function () {
var strName = "";
var wesRM = $('#acs-reader-message');
if (i_need_listselect()) {
$(g_objGMaker[gmOffset].gmProperties.strControl).hide();
$(g_objGMaker[gmOffset].gmProperties.strPanel).show();
$(g_objGMaker[gmOffset].gmProperties.strWindow).hide();
wesRM.html('List of filter setups');
$('#acs-filter-new').hide();
$('#acs-filter-refresh').hide();
$('#acs-filter-returnlist').hide();
When you code up JS like this you appreciate why the {} brackets and ; terminators are needed!Code:}
o.ready = true;
}
return {
load: function (i, o) {
var loadOffset = -1;
var foundFId = false;
for (var j = 0; j < g_objGMaker.length; j++) {
if ((g_objGMaker[j].fid != null) && (g_objGMaker[j].fid == o.fid)) {
foundFId = true;
break;
}
}
.
.
.
},
create: function (s) {
var sName = "";
.
.
.
}
};
};
When you need this class you make it like this
This allows me to organize my code just like any other higher level language. Basically it's all up to me how I use these concepts.Code:var gridworker = new grid_maker();
And don't let me start talking about CLOSURE! You all recently got lambda functions in .Net - that's a taste of how the JS world rocks.
Oh and thanks for mentioning SlickGrid and jqplot. I will probably end up using them in my application. I am pretty much developing my portal feature by feature as they are required. So we haven't needed graphing or grids, but I know they are going to want me to start plotting data for their year-end stats.
Dylan
My backend releases CRUD at times, but never Java.
I don't think closures originated in JavaScript. They exist in languages where functions are first class objects and I believe there are older languages(functional languages in particular) than JavaScript that implement closures.Quote:
Originally Posted by szlamany
It seems closures were first used in PAL.
ah yes - back on topic...Quote:
Originally Posted by Shaggy Hiker
It's the "why" closures are so cool that's meaningful.Quote:
Originally Posted by Niya
When you have a user stay on a static web page - no GET's for a new page load - you end up being FULLY asynchronous.
So it's a natural need to release variables into closure so that when the callback function eventually gets called you have references to work against.
Here I have a function that submits an AJAX call to the backend server. Notice that I pass in "objWebParam" and "sender". In the $.AJAX() call I pass in "instances" of new functions that will run in the event that this AJAX call returns from the server. The NEW FUNCTION calls have references to "objWebParam" and "sender" - they just stay in scope long enough to handle the eventual running of these function calls.
I don't have to worry about SCOPE or creating some mechanism to retain and pass values.
You should also notice that the argument to the $.AJAX() function call is an OBJECT of NAME / VALUE pairs. Some are easy NAMES and values. One value is a STRING. Some values are function being created. JS is a really loose language and that's powerful - be careful is all you have to be.Code:function submitAjax(strService, objWebParam, sender, fncFinished) {
var objSubmit = {};
mergeObjects(objSubmit, objWebParam);
clearWebParam(objSubmit);
var strWebParam = $.toJSON(objSubmit);
$.ajax({
type: "POST",
url: "WebService.asmx/" + strService,
dataType: "json",
data: strWebParam,
contentType: "application/json; charset=utf-8",
success: function(msg) {
fncFinished(msg, sender, "success", objWebParam);
},
failure: function(msg) {
fncFinished(msg, sender, "failure", objWebParam);
},
error: function(msg) {
fncFinished(msg, sender, "error", objWebParam);
}
});
}
You don't have to tell me....closures are the reason I can do stuff like this:-Quote:
Originally Posted by szlamany
vbnet Code:
The above is an extract from my pet project, Demon Arena. Its a creature definition. Its a list that is basically a short program that describes how the creature behaves. Notice that a lot of it is made up of EMCD calls which are subs in the base class. Thanks to lambdas, I can embed function calls right into the definition. Closures make it possible to refer to stats such a its speed, which is implemented as a property, from these lambda calls if I so desired. Lambdas and closures allowed me to develop this system which was quite impossible in VB6. So I know just how powerful lambdas and by extension, closures can truly be.
I wanted to do something like this in the VB6 version but that would have required me to represent each ECMD call as strings, create a mapping that maps the strings to the proper method call and it would require me to create a parser and lexical analyzer to parse parameters, do data validation and syntax checking. Trust me, this is no easy task. Parsers and lexical analyzers that work properly are no easy feat to write. It would have requires almost as much effort as the 2D engine itself. That was unacceptable, so I was stuck defining entities in a ad-hoc and inflexible way. Lambdas made it possible to design the system the way I wanted.
This was one of the projects by the way which showed me just how outdated are archaic VB6 really is when compared to C# and VB.Net. That is why it irks me when people try to paint VB6 and the second coming of Christ. These people really have no idea what they're talking about.
Good stuff - nice to see.Quote:
Originally Posted by Niya
I totally agree - MS has done a nice job of advancing the syntax of VB - incorporating all kinds of useful constructs and advanced techniques.Quote:
Originally Posted by Niya
That should be reason enough to leave a language like VB6.
The only reason I landed in JavaScript (from VB6) was ASP.Net - with those painful backend VB methods that try to emulate "some event model" - not sure which one!
Hidden in that mess is just JavaScript/AJAX with a lot of "maintain-state" bloat.
I did one client implementation with ASP.net and realized that I was coding each form and use-model nearly from scratch. Buried in HTML is code hooks - buried in code is HTML hooks - all painfully laid out in the most verbose blather.
I like a lot more code reuse for each client facing form. It's just a matter of economy of time.